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 19:46:34
Message-ID: 26595.1538423194@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:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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........"

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-10-01 19:54:59 Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Previous Message Stephen Frost 2018-10-01 19:39:14 Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)