Re: help: now() + N is now failing!

From: Dmitry Tkach <dmitry(at)openratings(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: mel(at)gmanmi(dot)tv, pgsql-novice(at)postgresql(dot)org
Subject: Re: help: now() + N is now failing!
Date: 2003-07-29 16:05:29
Message-ID: 3F269B49.4050101@openratings.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Tom Lane wrote:

>Dmitry Tkach <dmitry(at)openratings(dot)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

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Lane 2003-07-29 16:17:04 Re: help: now() + N is now failing!
Previous Message Dmitry Tkach 2003-07-29 16:01:39 Re: help: now() + N is now failing!