Tom Lane wrote:
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.
I think if we say that functions can be used as table attributes, and types can be used as (cast) functions, and tables are types, then we are simply stuck with the current behavior. Individually, these all make sense, so you can't break that chain without some really complicated warts.
