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 по дате отправления: