Re: Restore enforce_generic_type_consistency's breaks a farms
От | Tom Lane |
---|---|
Тема | Re: Restore enforce_generic_type_consistency's breaks a farms |
Дата | |
Msg-id | 2585.1229359133@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Restore enforce_generic_type_consistency's breaks a farms (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Restore enforce_generic_type_consistency's breaks a farms
|
Список | pgsql-hackers |
I wrote: > ... But this type of problem has come > up before. I wonder if we shouldn't do what was previously discussed: > make has_table_privilege and related functions silently return FALSE, > instead of throwing error, when given a "nonexistent" OID. On checking the archives, it seems most of the previous complaints have been about "cache lookup failed" errors arising from pg_table_is_visible and its ilk; those are used in the queries generated by psql's \d commands. So my proposal is to change the OID-accepting variants of has_table_privilege and friends, as well as pg_table_is_visible and friends, to silently return FALSE instead of failing when given a bad OID. I had originally thought we might change the underlying functions (pg_class_aclcheck, RelationIsVisible, etc) but it looks like it'd be better to expend a SearchSysCacheExists call in the SQL-accessible functions. (This doesn't leave a race condition since there'd not be any check for syscache invalidation messages between the SearchSysCacheExists and the ensuing lookup.) regards, tom lane
В списке pgsql-hackers по дате отправления: