Dean Rasheed <dean_rasheed@hotmail.com> writes:
>> foo.char and foo.varchar have similarly unexpected behavior; I think
>> that's probably the end of it, though, since those are the only types
>> that CoerceViaIO will take as targets.
> ... and also any user defined domains based on those, which is
> what I actually had.
Ouch. That makes the scope for unexpected behavior wider than I thought.
Maybe we do need some restriction here?
The ideas I had involved not considering the cast interpretation when
the actual syntax is table.column and some-set-of-other-conditions.
While this is certainly possible to implement, any variant of it will
break the existing 100% equivalence of foo.bar and bar(foo); which
seems to me to be a nice principle, though I grant you won't find it
anywhere in the SQL standard.
The other-conditions are a bit up for grabs. The narrowest restriction
that would serve the purpose is "table variable is of composite type
and the cast would be a CoerceViaIO cast", but that definitely seems
like a wart. However, cleaner-seeming restrictions like "no casts on
composites at all" could potentially break applications that worked
okay before 8.3.
Comments anyone? Should we try to change this, or leave well enough
alone?
regards, tom lane
