Repetition of warning message while REVOKE
in [PgSql]
|
From: Tom Lane on 4 Mar 2010 10:27 Piyush Newe <piyush.newe(a)enterprisedb.com> writes: > create table tbl(col int); > create user usr; > grant select on tbl to usr; > \c postgres usr; > REVOKE SELECT on tbl from usr; > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > WARNING: no privileges could be revoked for "tbl" > REVOKE You really should mention what version you're testing, but for the archives: I confirm this on 8.4.x and HEAD. 8.3 seems to behave sanely. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 4 Mar 2010 11:23 I wrote: > Piyush Newe <piyush.newe(a)enterprisedb.com> writes: >> create table tbl(col int); >> create user usr; >> grant select on tbl to usr; >> \c postgres usr; >> REVOKE SELECT on tbl from usr; >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> WARNING: no privileges could be revoked for "tbl" >> REVOKE > You really should mention what version you're testing, but for the > archives: I confirm this on 8.4.x and HEAD. 8.3 seems to behave sanely. I traced through this and determined that the extra messages are a consequence of the column-level-privileges patch. restrict_and_check_grant is invoked both on the whole relation, and on each column (since we have to get rid of any per-column SELECT privilege that might have been granted). I'm not sure offhand about a reasonable way to rearrange the code to avoid duplicate messages. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 4 Mar 2010 11:32 On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote: > I wrote: > > Piyush Newe <piyush.newe(a)enterprisedb.com> writes: > >> create table tbl(col int); > >> create user usr; > >> grant select on tbl to usr; > >> \c postgres usr; > >> REVOKE SELECT on tbl from usr; > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> WARNING: no privileges could be revoked for "tbl" > >> REVOKE > > > You really should mention what version you're testing, but for the > > archives: I confirm this on 8.4.x and HEAD. 8.3 seems to behave sanely. > > I traced through this and determined that the extra messages are a > consequence of the column-level-privileges patch. > restrict_and_check_grant is invoked both on the whole relation, and > on each column (since we have to get rid of any per-column SELECT > privilege that might have been granted). > > I'm not sure offhand about a reasonable way to rearrange the code to > avoid duplicate messages. Perhaps just add what can't be revoked? meaning: WARNING: no privileges could be revoked for "tbl" for column "foo" Then they aren't actually duplicate. Sincerely, Joshau D. Drake > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 4 Mar 2010 22:41 All, * Joshua D. Drake (jd(a)commandprompt.com) wrote: > On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote: > > I'm not sure offhand about a reasonable way to rearrange the code to > > avoid duplicate messages. > > Perhaps just add what can't be revoked? meaning: > WARNING: no privileges could be revoked for "tbl" for column "foo" > Then they aren't actually duplicate. Yeah, they really aren't, after all. I don't know how we could rearrange the code to prevent it- we're checking and trying to change privileges on each of the columns in the table, after all. Attached is a patch to add column name to the error message when it's a column-level failure. I'm not really thrilled with it, due to the expansion of code and addition of a bunch of conditionals, but at least this isn't a terribly complicated function.. In the process of trying to build/run regression tests, but having some build issues w/ HEAD (probably my fault). Thanks, Stephen
From: Tom Lane on 4 Mar 2010 23:00
Stephen Frost <sfrost(a)snowman.net> writes: > * Joshua D. Drake (jd(a)commandprompt.com) wrote: >> Perhaps just add what can't be revoked? meaning: >> WARNING: no privileges could be revoked for "tbl" for column "foo" >> Then they aren't actually duplicate. > Yeah, they really aren't, after all. Yeah, I agree JD's solution is probably the simplest reasonable answer. > Attached is a patch to add column name to the error message when it's a > column-level failure. I'm not really thrilled with it, due to the > expansion of code and addition of a bunch of conditionals, but at least > this isn't a terribly complicated function.. It's a bit brute-force, but so was the original coding. Anybody see a way to make it cleaner/shorter? One thought is that the column cases should be phrased more like no privileges could be revoked for column "foo" of table "bar" Check the messages associated with DROP cascading for the canonical phrasing here, but I think that's what it is. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |