Re: Possibly inconsistent type casting logic

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> In the old days, when every function of the form foo(bar) was a cast from
> bar to foo, and if foo and bar happened to be binary compatible, the
> system short-circuited this function call to do a "zero-effort" cast.

More accurately, it would assume you meant foo(bar) as a cast, and would
implicitly turn it into bar::foo.

> This logic still exists, but since in general casts are controlled
> through pg_cast now, it seems inconsistent that the old system still
> exists in some places. Did we forget that or is that intentional?

It was intentional. People are used to using foo(bar) as a cast syntax;
whether it happens to correspond to an actual function call by exactly
that name or not is not really important to them. This behavior is
documented, too:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS
I don't want to break the functional notation where we don't have to.

> The consequence of this feature put in other words appears to be that "if
> you create a binary-compatible cast from foo to bar, a function 'bar(foo)
> returns bar' will magically appear to exist". Maybe that's fine, but then
> we should probably document it more explicitly.

If there is any change required here, I'd lean to recommending more
strongly (or even enforcing?) that functions implementing type casts be
named for the target type, so that people don't get unexpected surprises
because the functional cast notation doesn't work.

regards, tom lane