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 20181001195459.GI4184@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:
> >> You can't have it both ways.  Either you throw an error if the name's
> >> not there, or you don't.
>
> > I'm not following why we couldn't handle a dropped column differently.
>
> Different from what?  A name-based lookup isn't going to find a dropped
> column, because its attname has been replaced with
> "........pg.dropped.N........"

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

> > Dropped tables don't hang around in the catalog long after they've been
> > dropped.
>
> If you are talking about the case where a lookup by attnum finds a dropped
> column, that does return null already, cf column_privilege_check().
> But I don't see a way for a name-based lookup to do the same without
> losing all semblance of error detection.

Perhaps it's not worth it then, though I still contend that it's pretty
annoying that we throw an error in that case.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Next
From: Peter Eisentraut
Date:
Subject: settings to control SSL/TLS protocol version