Re: New patch for Column-level privileges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New patch for Column-level privileges
Date
Msg-id 26466.1231860196@sss.pgh.pa.us
Whole thread Raw
In response to Re: New patch for Column-level privileges  (Stephen Frost <sfrost@snowman.net>)
Responses Re: New patch for Column-level privileges
List pgsql-hackers
Stephen Frost <sfrost@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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New patch for Column-level privileges
Next
From: Alvaro Herrera
Date:
Subject: Re: Patch for str_numth() in PG 7.4