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

From Stephen Frost
Subject Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)
Date
Msg-id 20181002104642.GL4184@tamriel.snowman.net
Whole thread Raw
In response to Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Having said that, I'm fine with having it return NULL if the given
> >> attname matches an attisdropped column.
>
> > Ok, that's really all I was asking about.
>
> Ah, we were just talking past each other then :-(.  That behavior existed
> already, it wasn't something my draft patch introduced, so I was confused
> what you were talking about.

No worries.

> >> ... What I was on about is what
> >> happens when you write
> >> has_column_privilege('sometab'::regclass, 'somecol', 'SELECT');
> >> and sometab exists but somecol doesn't.
>
> > Yeah, having that throw an error seems reasonable to me.
>
> 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.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: pg_ls_tmpdir()
Next
From: Laurenz Albe
Date:
Subject: Re: pg_ls_tmpdir()