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
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! |