Re: help: now() + N is now failing!
От | Dmitry Tkach |
---|---|
Тема | Re: help: now() + N is now failing! |
Дата | |
Msg-id | 3F269B49.4050101@openratings.com обсуждение исходный текст |
Ответ на | Re: help: now() + N is now failing! (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: help: now() + N is now failing!
|
Список | pgsql-novice |
Tom Lane wrote: >Dmitry Tkach <dmitry@openratings.com> writes: > > >>I guess, the now()+2 has the same problem - for some reason, it fails to >>coerce timestamptz into date automatically :-( >>Why is that? There is only one function called date_pli(), and there is >>an unambigous conversion date(timestamptz)... Why does it now force the >>user to cast explicitly??? >> >> > >Because it's an information-losing coercion. > >To reduce the odds that a surprising interpretation will be chosen, we >have tightened the casting rules so that only up-promotions and not >down-promotions will happen implicitly within expressions. > Ouch! Without getting into arguing the rationale of this decision, isn't it going to be *tons* of the application code, that will stop working after the migration? :-( > >As a comparison point, you would like float8 + int4 to be done in >float8 rather than int4 arithmetic, would you not? If both directions >of casting are equally implicit then there's no basis for the parser to >choose the preferred operator. > Well... the basis would be to prefer up-promotion over a down-promotion, for example... Or, if they both are the same direction, then, yes, I agree, that it is ambigous, and should cause an error... But in cases like date_pli (now(), 2) - there is only one alternative, thus no ambiguity - why not just do it? Dima
В списке pgsql-novice по дате отправления: