Dean Rasheed <dean_rasheed@xxxxxxxxxxx> 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
