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.
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.
An alternative approach for Mel to fix his problem is to change the
pg_cast entry for timestamptz-to-date to allow it to happen implicitly,
but (a) that might have unforeseen side effects in other contexts, and
(b) it wouldn't get dumped by pg_dump, as a custom operator will.
regards, tom lane