From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
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:17:04 |
Message-ID: | 22708.1059495424@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> But in cases like date_pli (now(), 2) - there is only one alternative,
> thus no ambiguity - why not just do it?
No, there are zero alternatives. And we're actually moving slowly on
this issue to make the transition less painful for people. If I had my
druthers 7.3 would have been much more draconian about implicit casts.
For an example of surprising behavior that is still there, reflect on
this open bug report:
http://archives.postgresql.org/pgsql-bugs/2001-10/msg00103.php
http://archives.postgresql.org/pgsql-bugs/2001-10/msg00108.php
The details have changed since 7.1, but we still end up comparing the
values as if they were text strings; and there is no way to avoid this
except to stop treating casts to text as implicitly invocable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Godshall Michael | 2003-07-29 16:18:38 | switch statement in plpgsql |
Previous Message | Dmitry Tkach | 2003-07-29 16:05:29 | Re: help: now() + N is now failing! |