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