Re: Bug Repoprt- Casting Issues - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug Repoprt- Casting Issues
Date
Msg-id 6584.960146814@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug Repoprt- Casting Issues  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> If you'd prefer not to be concerned about the intermediate conversion
>> to abstime, then use the date() notation.  The :: notation is designed
>> for controlling the type conversion exactly.

> Wow, that is definitely confusing. I had always thought that `::' is
> "cast, no matter how", and date() is "call the function date, which
> happens to do the conversion". But now it seems that the supposed "cast"
> syntax is really just a dumb function call whereas the function syntax
> actually does more intelligent work behind the scenes.

Actually, most of the "intelligence" falls out of the fact that the
system is willing to do type-coercions to make the inputs to a function
call match the requirements of the called function.  So when you write
date(int4var) you are actually getting date(int4var::abstime).

While it may seem confusing, I don't see a better alternative.  The
usability of the system would be greatly reduced if we didn't perform
implicit type conversion of function inputs (unless we created a much
larger number of functions than we have now).  OTOH, I don't think that
foo::bar should be willing to detour silently through several other
types to make the conversion from foo to bar...

> I have a feeling these type conversion issues aren't going away for a long
> time...

We could do with some better documentation on the subject, at least.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Bug Repoprt- Casting Issues
Next
From: Karl DeBisschop
Date:
Subject: Solaris compile problem