From: | " " <wilma(dot)wantren(at)eclipso(dot)de> |
---|---|
To: | "Wetmore, Matthew (CTR)" <Matthew(dot)Wetmore(at)express-scripts(dot)com> |
Cc: | <wilma(dot)wantren(at)web(dot)de>, <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #18249: pg_dump/pg_restore single schema with function1 calling function2 |
Date: | 2023-12-18 10:19:24 |
Message-ID: | de028f0738e33eae284befcd687b41e1@mail.eclipso.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thanks a lot for your swift response!
In oder to make this call in function1
begin return str || 'hello' || function2(str);
work independently of the session search_path, either the line must read
begin return str || 'hello' || dumper.function2(str);
or the function must get a search_path:
alter function dumper.function1 set search_path to dumper;
Neither of these will be changed when the schema is renamed. I am not criticizing this, of course it will not be changed! But this also means that I have to know that I must change the search_path of function function1 (or even change the function body) after renaming the schema. This is unpleasant, especially because renaming the schema is otherwise so wonderfully unproblematic and simple.
Is it possible to set the search_path of a function to "the schema of the function", e.g. like this:
alter function dumper.function1 set search_path to function_schema();
Then the search_path would still be correct after renaming the schema.
--- Ursprüngliche Nachricht ---
Von: "Wetmore, Matthew (CTR)" <Matthew(dot)Wetmore(at)express-scripts(dot)com>
Datum: 15.12.2023 15:29:38
An: "wilma(dot)wantren(at)web(dot)de" <wilma(dot)wantren(at)web(dot)de>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Betreff: BUG #18249: pg_dump/pg_restore single schema with function1 calling function2
Not to be trite, but schema qualifying your function/tables would have prevented
this.
create or replace function MYSCHEMA.function1(str varchar) returns varchar
as $$ begin return str || 'hallo' || function2(str); end; $$ language plpgsql
strict immutable;
relying on search_path is a dangerous games. Be specific in your SQL and
you'll get better long term results.
Then if the schema name changes, everything downstream changes too. Or you
can edit the dump.sql
-----Original Message-----
From: PG Bug reporting form <noreply(at)postgresql(dot)org>
Sent: Friday, December 15, 2023 1:09 AM
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: wilma(dot)wantren(at)web(dot)de
Subject: [EXTERNAL] BUG #18249: pg_dump/pg_restore single schema with function1
calling function2
The following bug has been logged on the website:
Bug reference: 18249
Logged by: Wilma Wantren
Email address: wilma(dot)wantren(at)web(dot)de
PostgreSQL version: 13.4
Operating system: All
Description:
The company I work for used to only use Oracle databases for their program
and now also supports PostgreSQL.
With Postgres, we create a database, a user and a schema, which all have
the same name. The name is chosen by the customers.
Nevertheless, the customers would like to export the data and definitions
and import them under a new name.
This works well by using the -O (no owner) option for pg_dump/pg_restore
and only exporting and importing the schema. After the import the schema
is renamed. So far so simple and easy!
But there is one problem: we have a database function function1, which calls
another function function2. The call is made without a schema prefix because
these are just two functions that we make available to the customers and
we don't think an extra schema for these two functions is worthwhile. However,
function1 is used in an index and the restore of the index fails if there
is data in the corresponding table column. This is because pg_dump/pg_restore
set the search_path to '' when restoring, which means that function1 cannot
find the function2.
Is there any way to solve this? It is not a big problem and we can tell the
customer to ignore the error message and recreate the indices after the import,
but it would be nicer without an error message.
Here are the steps to reproduce:
Contents of file "create_dumper.sql":
create user dumper;
create database dumper owner dumper;
alter user dumper set search_path to dumper; \c dumper dumper; create schema
dumper; create or replace function function2(str varchar) returns varchar
as $$ begin return str || str; end; $$ language plpgsql strict immutable;
create or replace function function1(str varchar) returns varchar as $$ begin
return str || 'hallo' || function2(str); end; $$ language plpgsql strict
immutable;
create table table1(str varchar not null); insert into table1 values('test');
create index index1 on table1(function1(str));
Call with
psql -f create_dumper.sql
Export:
pg_dump -h localhost -p 5432 -U dumper --schema dumper -O -f dumper.sql
Contents of file "create_restorer.sql":
create user restorer;
create database restorer owner restorer;
Call with:
psql -f create_restorer.sql
Import:
psql restorer restorer -f dumper.sql
________________________________________________________
Your E-Mail. Your Cloud. Your Office. eclipso Mail & Cloud. https://www.eclipso.de
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-12-18 16:00:02 | BUG #18252: Assert in CheckOpSlotCompatibility() fails when recursive union filters tuples in non-recursive term |
Previous Message | Junwang Zhao | 2023-12-18 09:12:45 | Re: BUG #18247: Integer overflow leads to negative width |