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 20181001211140.GJ4184@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:
> > My complaint is specifically trying to do something like:
[...]
> That code is kinda broken anyway, because it won't survive relation drops
> either.  What you *should* be writing is

Yes, I agree, but it still seems like we're throwing an ERROR
unnecessairly.

> 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.

> ... 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.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Odd 9.4, 9.3 buildfarm failure on s390x
Next
From: Larry Rosenman
Date:
Subject: Re: Odd 9.4, 9.3 buildfarm failure on s390x