Kevin Grittner <kgrittn@gmail.com> writes:
> On Tue, Dec 8, 2015 at 10:24 AM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> While you've explained how to see what is happening it doesn't remove
>> the POLA violation that has occurred here.
> I tend to think of x.* as being something that is resolved at parse
> analysis time, before any consideration is given to how to execute;
> thus, when x is a function I didn't find it at all astonishing that
> it resolved as above.
As far as table references go, it's effectively required by the SQL spec
that "tab.*" in a SELECT list is expanded to "tab.c1, tab.c2, etc" at
parse time. (I draw this conclusion from the parts of the spec that say
that tab.*'s meaning in a view referencing tab does not change if tab
subsequently gains new columns.)
It's definitely annoying that (foo()).* is expanded similarly; but to fix
that we'd have to introduce an additional layer of evaluation into SELECT
lists, and I think that might create some visible semantic oddities of its
own. Between backwards-compatibility worries and the existence of the
LATERAL workaround, it's unlikely we'll ever change this.
I'm not sure how well this point is documented, though. Might be worth
some effort in that direction.
regards, tom lane
