Stephen Frost <sfr...@snowman.net> writes:
>> It's possible that we've missed some --- in particular, right at the
>> moment I am not sure that whole-row Vars are handled properly.
> I added specific regression test for whole-row Vars, so I'd be concerned
> if something isn't working there.
What I see being tested is SELECT *, which is a different animal
entirely. As required by spec, SELECT * is expanded to a list of
ordinary variables at parse time and then it's not really a special
case anymore. A true whole-row variable only occurs when you have
something like
create function myfunc(mytable) ...
select myfunc(mytable.*) from mytable ...
This is different from the *-expansion case in that you get just
a single Var with attno 0 in the resulting parse tree. And the
reason for the different representation is that the semantics
are different. If the user later does ALTER TABLE ADD COLUMN,
the whole-row Var now implicitly includes that column too, whereas
existing views defined with SELECT * do not (read the spec).
Because of this action-at-a-distance in terms of what columns are
implicitly referenced, I think that the only feasible implementation is
to carry the "reference to column 0" notation in cols_sel right through
to execMain, and have execMain understand that as demanding select
rights on all currently existing non-dropped non-system columns.
I have not yet checked to see if that's what actually happens;
but it's certainly not being exercised in the added regression tests.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
