Thread: Possibly inconsistent type casting logic
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
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
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, Pennsylvania19073