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

Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> Tom Lane wrote:
>> 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?

No, that only masks the problem: the real problem IMHO is precisely that
the system may select a surprising conversion if the conversion you were
expecting doesn't exist. (Sometimes even if it *does* exist.) The more
implicit conversions there are, the bigger the risk that the parser will
do something you didn't expect.

If we go down the path you propose, we might as well not have a type
system at all, because we will end up with anything implicitly
convertible to anything else. But long before then, it'll stop being
a useful system, because the parser will be unable to pick any operators
due to having too many possible interpretations.

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

One of the problems people have with using C++ that way is that the
compiler tends to pick unexpected interpretations --- which is exactly
the problem I'm complaining about for Postgres. Ask anyone who's worked
on large systems in C++, they'll have some horror stories to tell you...

regards, tom lane