On Sun, Jun 5, 2016 at 12:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
