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 по дате отправления:

Предыдущее
От: Luca Ferrari
Дата:
Сообщение: Re: pg_visible_in_snapshot clarification
Следующее
От: Jethro Elmer Sanidad
Дата:
Сообщение: Re: [EXTERNAL] Oracle FDW version