Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
| От | Tom Lane |
|---|---|
| Тема | Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c) |
| Дата | |
| Msg-id | 22624.1538495933@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c) (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)
|
| Список | 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 по дате отправления: