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.

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?

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.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 24 Feb 2003 20:16:44 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Possibly inconsistent type casting logic
Peter Eisentraut <peter_e@gmx.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

Mon, 24 Feb 2003 16:23:44 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Possibly inconsistent type casting logic 

Did this get resolved?

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> 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.
> 
> 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?
> 
> 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.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 17 Mar 2003 14:43:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Possibly inconsistent type casting logic