Greetings, * Tom Lane ([email protected]) wrote: > Stephen Frost <[email protected]> writes: > > * Tom Lane ([email protected]) 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!
Thanks for hacking on it.
> 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)
Ah, yeah, that's the whole "you have access to all columns if you have
SELECT rights on the table".
> 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.
Yeah, I'm on the fence about if it makes sense to do anything here or
not. Hard to see how getting a NULL back is really more useful in this
case.
Thanks!
Stephen
signature.asc
Description: PGP signature
