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 27933.1538425639@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:
> 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SerializeParamList vs machines with strict alignment
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: buildfarm and git pull