Re: Cache lookup errors with functions manipulation object addresses - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Cache lookup errors with functions manipulation object addresses
Date
Msg-id C419F9C4-860A-4A87-9A3A-819EDFD25A4B@yesql.se
Whole thread Raw
In response to Re: Cache lookup errors with functions manipulation object addresses  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Cache lookup errors with functions manipulation object addresses  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> On 2 Jul 2020, at 07:35, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Mar 19, 2020 at 10:30:11PM +0900, Michael Paquier wrote:
>> The new FORMAT_TYPE_* flag still makes sense to me while reading this
>> code once again, as well as the extensibility of the new APIs for
>> operators and procedures.  One doubt I still have is if we should
>> really change the signature of getObjectDescription() to include the
>> new missing_ok argument or if a new function should be introduced.
>> I'd rather keep only one function as, even if this is called in many
>> places in the backend, I cannot track down an extension using it, but
>> I won't go against Alvaro's will either if he thinks something
>> different as this is his original design and commit as of f8348ea3.
>
> Attached is an updated patch set, because of conflicts in the docs.
> Daniel, you are still registered as a reviewer of this patch, and it
> is marked as ready for committer?  Do you have more comments?  Would
> anybody have objections if I move on with 0001 and 0002 that extend
> the APIs to get the procedure, operator and type names?

No objections from me after skimming over the updated patchset.  I still
maintain that the format_operator_extended comment should be amended to include
that it can return NULL and not alwatys palloced string, but that's it.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Creating a function for exposing memory usage of backend process
Next
From: Fujii Masao
Date:
Subject: Re: track_planning causing performance regression