|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: Cache lookup errors with functions manipulation object addresses|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Dec 14, 2018 at 09:04:36AM +0900, Michael Paquier wrote:
> Thanks again for looking up at what was proposed. I'll see if I can
> finish the refactoring part for the next CF, and be done with this
Please find attached an updated patch set which reworks the SQL
interface for object addresses so as NULL-ness is handled consistently
for all object types. This has needed a couple of extensions to some
current object-lookup APIs, which are added as refactoring bits
without breaking existing callers:
- Procedures and operators gain a new _extended routine which can take
a set of flags to enforce a NULL result or force qualification.
- format_type_extended needs an extra flag to enforce NULL.
On top of the refactoring issues, here is the list of changes to make
- The object type can never be NULL, meaning that for undefined
relations, routines or constraints the caller gets a generic name even
if the object is not defined. (That's the definition mentioned a
couple of messages upthread).
- Large object existence is checked with LargeObjectExists().
- Table columns show all the fields as NULL if the object identity
cannot be found instead of showing the table and its schema.
With that all the regression tests show a consistent behavior for all
object types when those are undefined. Thoughts?
|Next Message||Iwata, Aya||2018-12-25 04:53:13||RE: libpq debug log|
|Previous Message||David Rowley||2018-12-25 02:48:30||Re: Performance issue in foreign-key-aware join estimation|