Re: pg_dump/pg_restore and the magic of the search_path
От | Erik Wienhold |
---|---|
Тема | Re: pg_dump/pg_restore and the magic of the search_path |
Дата | |
Msg-id | 1686822272.145805.1693518460997@office.mailbox.org обсуждение исходный текст |
Ответ на | pg_dump/pg_restore and the magic of the search_path (Arthur Bazin <arthurbazin@gmail.com>) |
Ответы |
Re: pg_dump/pg_restore and the magic of the search_path
|
Список | pgsql-general |
> On 31/08/2023 17:08 CEST Arthur Bazin <arthurbazin@gmail.com> wrote: > > Consider that we have a function in the public schema witch is named > my_function_in_public. > > In PG11 this table : > CREATE TABLE public.test_dump ( > id TEXT DEFAULT my_function_in_public() > ); > When you dump this table with the pg11 binaries, you obtain this script : > CREATE TABLE public.test_dump ( > id TEXT DEFAULT public.my_function_in_public() > ); > => the schema prefix have been added to the function by pg_dump. > > In PG13, the same table : > CREATE TABLE public.test_dump ( > id TEXT DEFAULT my_function_in_public() > ); > When you dump this table with the pg13 binaries, you obtain this script : > CREATE TABLE public.test_dump ( > id TEXT DEFAULT my_function_in_public() > ); > => the schema prefix have not been added. Are you sure that my_function_in_public was created in schema public on pg13? I cannot reproduce this on 13.12. However, I can reproduce it when creating that function in pg_catalog instead of public. The dump does not include pg_catalog.my_function_in_public though. -- Erik
В списке pgsql-general по дате отправления: