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
