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

From Wilma Wantren
Subject Re: Re: Changing a schema's name with function1 calling function2
Date
Msg-id 4e095fdb84fb5b587e8aa975a2940fc2@mail.eclipso.de
Whole thread Raw
In response to Re: Changing a schema's name with function1 calling function2  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
That's really nice of you to point me to this mailing list! I'll make my suggestion there in the next few days.
I don't think it's so bad if the new feature is not available until fall 2024 or even later, the time in which it's
usefulwould be very long in any case. 
Happy New Year to you and thanks again
Wilma

--- Ursprüngliche Nachricht ---
Von: Adrian Klaver <adrian.klaver@aklaver.com>
Datum: 30.12.2023 19:05:28
An: Wilma Wantren <wilma.wantren@eclipso.de>
Betreff: Re: Changing a schema's name with function1 calling function2

On 12/30/23 08:01, Wilma Wantren wrote:
> Thank you all, and especially you, Adrian, for your answers.
> However, I find the last suggestion too complicated. In Peter's words
I had suggested a "magic variable" __function_schema__ which can
be set as the search_path of a function to select - when executing the function
- the schema the function actually is in. ("when executing", and
not "when setting the search_path")
> This would have been very easy to use and in the implementation of __function_schema__
it would have been possible to determine and cache the variable value (i.e.
the schema of the function) directly when setting the search_path, and to
redetermine and cache the variable value only when the function's schema
changes.

This is still not out of the realm of possibility, it would require
getting a developer or developers interested in it. The place to make
that argument is the hackers list:

https://www.postgresql.org/list/pgsql-hackers/

Though the earliest that could be incorporated into Postgres would be
the next major release Fall of 2024. This is dependent on getting the
code in before the feature freeze Spring(?) of 2024.


> Instead, I should now call the - actually diagnostic - function PG_ROUTINE_OID
from the body of my function, with which I get the OID of my function in
order to then determine the schema of my function and set it as search_path.
I don't think that suits my requirements.
>
> I will therefore consider using a database change management system
instead (e.g. sqitch, suggested by Adrian) and defining there what should
happen when the schema name is changed, including the names of all functions
whose search_path is to be changed.
>
> Many thanks again
> Wilma
>

--
Adrian Klaver
adrian.klaver@aklaver.com



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





pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Changing a schema's name with function1 calling function2
Next
From: Hao Zhang
Date:
Subject: Re: Read write performance check