Re: shoud be get_extension_schema visible? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: shoud be get_extension_schema visible?
Date
Msg-id 20230306073331.eoe46aibinyoof5k@jrouhaud
Whole thread Raw
In response to Re: shoud be get_extension_schema visible?  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: shoud be get_extension_schema visible?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Hi,

On Sun, Feb 19, 2023 at 06:40:39AM +0100, Pavel Stehule wrote:
>
> pá 17. 2. 2023 v 6:45 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
> napsal:
>
> > more times I needed to get the extension's assigned namespace. There is
> > already a cooked function get_extension_schema, but it is static.
> >
> > I need to find a function with a known name, but possibly an unknown
> > schema from a known extension.
> >
>
> Here is an patch

The patch is trivial so I don't have much to say about it, and it also seems
quite reasonable generally.

Note for other reviewers / committers: this is a something actually already
wanted for 3rd party code.  As an example, here's Pavel's code in plpgsql_check
extension that internally has to duplicate this function (and deal with
compatibility):
https://github.com/okbob/plpgsql_check/blob/master/src/catalog.c#L205

I'm marking this entry as Ready For Committer.



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Next
From: Pavel Stehule
Date:
Subject: using memoize in in paralel query decreases performance