Re: Re: Changing a schema's name with function1 calling function2 - Mailing list pgsql-general

Great that you have discussed this further! And sorry that what I wrote is apparently still misleading.
Peter understood me correctly, "__function_schema__ always refers to the schema the function actually is in".
I define:
1. create function my_schema.function1...
2. alter function function1 set search_path to __function_schema__
The variable __function_schema__ is not evaluated, but is set "as it is" in the metadata of the function, which
thereforereads:  
...
search_path: __function_schema__
...
Only when function1 is executed the variable is evaluated, namely "to the schema the function actually is in", in this
caseto 'my_schema'. If the schema is renamed, the search_path of function1 does not have to be changed, and is
neverthelessevaluated correctly again when the function is executed, now to the new schema name. 

--- Ursprüngliche Nachricht ---
Von: "Peter J. Holzer" <hjp-pgsql@hjp.at>
Datum: 25.12.2023 15:37:26
An: Adrian Klaver <adrian.klaver@aklaver.com>
Betreff: Re: Changing a schema's name with function1 calling function2

On 2023-12-24 14:27:19 -0800, Adrian Klaver wrote:
> On 12/24/23 13:43, Peter J. Holzer wrote:
> > I think you misunderstood Wilma. What she is asking for is a "keyword"

> > or "magic variable" (or whatever you want to call it)
which you can
> > specify in CREATE|ALTER FUNCTION ... SET SEARCH_PATH = ..., which
refers
> > to the schema the function is (being) created in.
>
> Maybe, but I don't think so. From one of Wilma's previous post:
>
> "Therefore it would be great if there was a variable which I could
set in a
> search_path (like the variable "$user") which denotes the
function's schema
> and which is only evaluated when the function is executed, i.e. the
variable
> would be the value of the function's search_path in the function's meta

> data. This variable, e.g. "$function_schema" would still denote
the correct
> schema after renaming the schema."

I interpreted that as meaning what I wrote above.

So we'll have to wait for Wilma to clarify what she really meant.


> It seems to be pretty tied to search_path. Now there is, from:
>
> https://www.postgresql.org/docs/current/catalog-pg-proc.html
>
> proconfig text[]
>
> Function's local settings for run-time configuration variables
>
> Though that is part of the function definition not the code inside the

> function as you show below. Also you would still need to determine what
was
> the appropriate schema before creating/altering the setting for the

> function.

"Determining the appropriate schema" is what - AIUI - the requested

magic variable is for.


> > So if you create the function with
> >
> >      create function foo (...)
> >      set search_path to __function_schema__
> >      $$ ... $$
> >
> > (using the "dunder" convention (from some other programming
languages)
> > to denote the magic variable/keyword)
> >
> > the search path would be set to whatever schema was first in the

> > search_path when the function was created.
>
> That assumes the first schema is the correct one. Not something that
could
> be counted on given search_path can be set any number of ways at any
time.

Yes, I was sloppy there. What I actually meant was "the first schema

where the user actually has permission to create a function" (and no

doubt that isn't 100% correct either). I would expect that in a
deployment situation that would be the first schema in the search_path,
but you are of course correct that this is not necessarily the case.
Anyway, that was only illustrative. The point of my examples was that no

matter how the function is created, __function_schema__ always refers to

the schema the function actually is in.

        hp


--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing

__/   | http://www.hjp.at/ |       challenge!"


________________________________________________________
Your E-Mail. Your Cloud. Your Office. eclipso Mail & Cloud. https://www.eclipso.de