Re: pg_dump/pg_restore and the magic of the search_path

From: Erik Wienhold <ewie(at)ewie(dot)name>
To: Arthur Bazin <arthurbazin(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: pg_dump/pg_restore and the magic of the search_path
Date: 2023-08-31 21:47:40
Message-ID: 1686822272.145805.1693518460997@office.mailbox.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On 31/08/2023 17:08 CEST Arthur Bazin <arthurbazin(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jethro Elmer Sanidad 2023-09-01 03:05:07 Re: [EXTERNAL] Oracle FDW version
Previous Message Luca Ferrari 2023-08-31 15:12:22 Re: pg_visible_in_snapshot clarification