Re: [sqlsmith] Failed assertion in joinrels.c
От | Michael Paquier |
---|---|
Тема | Re: [sqlsmith] Failed assertion in joinrels.c |
Дата | |
Msg-id | CAB7nPqRhSh1RrYRnGnk_5DZP8WoKNMuYeL4ed3LEmgQjpZHfpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Failed assertion in joinrels.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [sqlsmith] Failed assertion in joinrels.c
|
Список | pgsql-hackers |
On Sun, Jun 5, 2016 at 12:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> This is still failing: >> =# select indexdef from pg_catalog.pg_indexes where indexdef is not NULL; >> ERROR: XX000: cache lookup failed for index 2619 >> LOCATION: pg_get_indexdef_worker, ruleutils.c:1054 >> Do we want to improve at least the error message? > > Maybe we should just make the function silently return NULL if the OID > doesn't refer to an index relation. There's precedent for that sort > of behavior ... For views it is simply returned "Not a view", and for rules that's "-". All the others behave like similarly to indexes: =# select pg_get_constraintdef(0); ERROR: XX000: cache lookup failed for constraint 0 =# select pg_get_triggerdef(0); ERROR: XX000: could not find tuple for trigger 0 =# select pg_get_functiondef(0); ERROR: XX000: cache lookup failed for function 0 =# select pg_get_viewdef(0);pg_get_viewdef ----------------Not a view (1 row) =# select pg_get_ruledef(0);pg_get_ruledef ----------------- (1 row) So yes we could just return NULL for all of them, or make them throw an error. Anyway, my vote goes for a HEAD-only change, and just throw NULL... This way an application still has the option to fallback to something else with a CASE at SQL level without using plpgsql to catch the error. Also, I have not monitored the code much regarding some code paths that rely on the existing rules, but I would imagine that there are things depending on the current behavior as well. -- Michael
В списке pgsql-hackers по дате отправления: