Re: pg_dump/pg_restore and the magic of the search_path - Mailing list pgsql-general

From Erik Wienhold
Subject Re: pg_dump/pg_restore and the magic of the search_path
Date
Msg-id 1686822272.145805.1693518460997@office.mailbox.org
Whole thread Raw
In response to pg_dump/pg_restore and the magic of the search_path  (Arthur Bazin <arthurbazin@gmail.com>)
Responses Re: pg_dump/pg_restore and the magic of the search_path
List 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 by date:

Previous
From: Luca Ferrari
Date:
Subject: Re: pg_visible_in_snapshot clarification
Next
From: Jethro Elmer Sanidad
Date:
Subject: Re: [EXTERNAL] Oracle FDW version