Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Date
Msg-id 22624.1538495933@sss.pgh.pa.us
Whole thread Raw
In response to Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> OK, so here's a patch that I think does the right things.
>> I noticed that has_foreign_data_wrapper_privilege() and some other
>> recently-added members of the has_foo_privilege family had not gotten
>> the word about not failing on bogus OIDs, so I also fixed those.

> I just glanced through it pretty quickly, but looks good to me.

Pushed with some test cases; thanks for reviewing!

BTW, I noticed while making the test cases that there are some odd-seeming
behaviors as a result of early exits from the test functions.  For
instance,

regression=# create table mytab(f1 int, f2 int);
CREATE TABLE
regression=# select has_column_privilege('mytab',99::int2,'select');
 has_column_privilege 
----------------------
 t
(1 row)

One might reasonably expect NULL there, but column_privilege_check
observes that you have table-level select privilege so it doesn't
bother to look up the column number.  Not sure if this is worth
doing something about.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Tuple conversion naming
Next
From: Stephen Frost
Date:
Subject: Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)