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.