Re: New patch for Column-level privileges

Stephen Frost <sfrost(at)snowman(dot)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