Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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!

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