Re: New patch for Column-level privileges
От | Tom Lane |
---|---|
Тема | Re: New patch for Column-level privileges |
Дата | |
Msg-id | 26466.1231860196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: New patch for Column-level privileges (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: New patch for Column-level privileges
|
Список | 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 по дате отправления: