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

From Adrian Klaver
Subject Re: Changing a schema's name with function1 calling function2
Date
Msg-id 9ed20788-82cd-4eba-a590-7a474ca570ef@aklaver.com
Whole thread Raw
In response to Re: Changing a schema's name with function1 calling function2  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: Changing a schema's name with function1 calling function2
List pgsql-general
On 12/24/23 13:43, Peter J. Holzer wrote:
> On 2023-12-23 08:31:39 -0800, Adrian Klaver 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."

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.

There is also:

pronamespace oid (references pg_namespace.oid)

The OID of the namespace that contains this function

which could be construed as '... the function meta data.', though its 
not strictly search_path. I could see that being part of some dynamic 
SQL to set the search_path.


> 
> 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.

> 
> If you create it with
> 
>      create function my_schema.foo (...)
>      set search_path to __function_schema__
>      $$ ... $$
> 
> it would be set to "my_schema".
> 
> And if you changed the schema with
> 
>      alter function foo set schema my_new_schema
> 
> it would be changed to "my_new_schema".
> 
> Personally I think that effect should be easy enough to create in your
> deployment or migration scripts but of course that assumes that you have
> such scripts. If you are doing your deployments manually (especially by
> cloning a template as described by Wilma) I can see how that feature
> would make things easier and/or reduce the risk of errors.
> 
>          hp
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




pgsql-general by date:

Previous
From: "Peter J. Holzer"
Date:
Subject: Re: Changing a schema's name with function1 calling function2
Next
From: "Peter J. Holzer"
Date:
Subject: Re: Changing a schema's name with function1 calling function2