Tom Lane wrote:
>Dmitry Tkach <dmitry@openratings.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.
>
>
Couldn't those problems be fixed by simply adding an implicit type
conversion from numerical types to interval?
I understand, that disallowing implicit casts alltogether is easier, and
more general (so that you don't need to care about every case
separately), but doesn't it take out lots of flexibility (and, what's
worse, break existing code, that used to work before)?
I don't know if this is a valid comparison, but a parallel with C++
comes to mind - if you have a two classess - Date and Timestamp:Date,
and a function
date_pli (Date, int) (or operator + (Date, int)), returning Date, it is
perfectly valid to pass a Timestamp into it, right? Why should it be
different in postgres (I know, you'll tell me that I can't do this trick
with a double (Timestamp) -> int (Date) cast in C++, but that's an
implementation detail - from the user perspective, why is it supposed to
matter how exactly dates and timestamps are represented internally?)
Dima