Cache lookup errors with functions manipulation object addresses
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Cc: moshe@neadwerx.com, Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2017-07-19T06:25:56Z
Lists: pgsql-hackers
Hi all,
Per an offline report from Moshe Jacobson, it is possible to trigger
easily cache lookup errors using pg_describe_object with invalid
object IDs and pg_describe_object(). I had a closer look at things in
this area, to notice that there are other user-facing failures as many
things use the same interface:
=# select pg_identify_object('pg_class'::regclass, 0::oid, 0);
ERROR: XX000: cache lookup failed for relation 0
=# select pg_describe_object('pg_class'::regclass, 0::oid, 0);
ERROR: XX000: cache lookup failed for relation 0
=# select pg_identify_object_as_address('pg_class'::regclass, 0::oid, 0);
ERROR: XX000: cache lookup failed for relation 0
As my previous opinion on the matter in
https://www.postgresql.org/message-id/87wpxfygg9.fsf@credativ.de, I
still think that "cache lookup" failures should not be things a user
is able to trigger at will, and that those errors should be replaced
by proper NULL results. That's clearly not an item for PG10, but we
could consider improving things for PG11. Still, we are talking about
adding NULLness handling in getObjectDescription(), which goes into
low-level functions to grab the name of some objects, and some of
those functions have their own way to deal with incorrect objects
(format_type_be returns "???" for example for functions).
Would we want to improve the error handling of such objects? Or that's
not worth the effort? Álvaro, what's your take on the matter as you
worked a lot on that?
Thoughts,
--
Michael
Commits
-
Eliminate cache lookup errors in SQL functions for object addresses
- 2a10fdc4307a 14.0 landed
-
Refactor routines for name lookups of procedures and operators
- aa38434824c4 14.0 landed
-
Add new flag to format_type_extended() to get NULL for undefined type
- 1185c782943c 14.0 landed
-
Introduce new extended routines for FDW and foreign server lookups
- 8fb569e978af 12.0 landed
-
Refactor routines for subscription and publication lookups
- 1d6fbc38d9ed 12.0 landed
-
get_relid_attribute_name is dead, long live get_attname
- 8237f27b504f 11.0 landed
-
Tweak parser so that there is a defined representation for datatypes
- a585c20d12d0 7.2.1 cited