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

From Tom Lane
Subject Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Date
Msg-id 27933.1538425639@sss.pgh.pa.us
Whole thread Raw
In response to Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> My complaint is specifically trying to do something like:

> =*# select *
> from
>   pg_class
>   join pg_attribute on (pg_class.oid = pg_attribute.attrelid)
>   join pg_namespace on (pg_class.relnamespace = pg_namespace.oid)
                                 
> where
>   has_column_privilege(quote_ident(nspname) || '.' || quote_ident(relname),attname,'SELECT');

> and getting this:

> ERROR:  column "........pg.dropped.2........" of relation "t1" does not exist

That code is kinda broken anyway, because it won't survive relation drops
either.  What you *should* be writing is

    has_column_privilege(pg_class.oid, attnum, 'SELECT');

which is not only not sensitive to these problems but significantly more
efficient.

Having said that, I'm fine with having it return NULL if the given
attname matches an attisdropped column.  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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SerializeParamList vs machines with strict alignment
Next
From: Andrew Dunstan
Date:
Subject: Re: buildfarm and git pull