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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Date: 2018-10-01 20:27:19
Message-ID: 27933.1538425639@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-10-01 20:43:37 Re: buildfarm and git pull
Previous Message Tom Lane 2018-10-01 20:21:52 Re: SerializeParamList vs machines with strict alignment