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

Thank you!
I had already feared that such a variable does not exist (because I had not found it). I think that's a pity, because I
suspectthat in at least 90% of the cases where a function needs a search_path, this variable would be the value of the
search_path,so that in 90% of the cases no change to the search_path would be necessary after renaming the schema.  
Many thanks for the reference to sqitch, I'll have a look at that now.


Translated with DeepL.com (free version)
--- Ursprüngliche Nachricht ---
Von: Adrian Klaver <adrian.klaver@aklaver.com>
Datum: 23.12.2023 01:09:12
An: Wilma Wantren <wilma.wantren@eclipso.de>
Betreff: Re: Changing a schema's name with function1 calling function2

On 12/22/23 15:09, Wilma Wantren wrote:
> Thank you for your response!
> No, this does not help me. I will try to explain better what I mean.
Our customers use our program with a Postgres database, user and schema,
which have the same name. The customer chooses the name. Let's say one customer
calls the database, user and schema 'my_things'.
> I want to create scripts for the customers with which they can export
the schema and import it into another database with a new schema name, let's
say one customer wants to import it as 'my_things1' (this schema belongs
to database 'my_things1').
> The export script calls pg_dump to export schema 'my_things'.
> The import script calls pg_restore to restore schema 'my_things' in
database 'my_things1' and then calls psql to change the schema name to 'my_things1'.

> Now there is function1 which its search_path set to 'my_things'. Because
the search_path is still set to 'my_things' after renaming the schema the
script must now call psql to change the function's search_path to 'my_things1'.

> This is not just one line more in the import script.
> It is a fact that I must know - if I did not know about function1's
search_path then there would be an error in the schema after renaming the
schema.
> And imagine if one day a colleague of mine implements a new function
which needs a search_path but the colleague forgets to adjust the import
script then again there is an error in the schema after renaming the schema.

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

There is no such variable. What you have available is what I showed before:


https://www.postgresql.org/docs/current/sql-alterfunction.html

"
configuration_parameter
value

      Add or change the assignment to be made to a configuration
parameter when the function is called. If value is DEFAULT or,
equivalently, RESET is used, the function-local setting is removed, so
that the function executes with the value present in its environment.
Use RESET ALL to clear all function-local settings. SET FROM CURRENT
saves the value of the parameter that is current when ALTER FUNCTION is

executed as the value to be applied when the function is entered.

      See SET and Chapter 20 for more information about allowed parameter


names and values.
"

The alternative is to create a migration process using scripts with
variable substitution outside the database. I do something similar using

Sqitch(https://sqitch.org/) and its template system:

https://sqitch.org/docs/manual/sqitch-add/

--
Adrian Klaver
adrian.klaver@aklaver.com



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