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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)
Дата
Msg-id 26595.1538423194@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)
Список pgsql-hackers
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........"

> 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)