Re: pg_dump fail to not dump public schema orders - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pg_dump fail to not dump public schema orders
Date
Msg-id CAKFQuwaOcYVrsELNiWceSt6o7uBZN5V1k3dzVdvak5gq5Cz9YQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump fail to not dump public schema orders  (Adrien Nayrat <adrien.nayrat@anayrat.info>)
Responses Re: pg_dump fail to not dump public schema orders
List pgsql-hackers
On Fri, May 29, 2020 at 7:42 AM Adrien Nayrat <adrien.nayrat@anayrat.info> wrote:
On 5/29/20 3:56 PM, David G. Johnston wrote:
> On Friday, May 29, 2020, Adrien Nayrat <adrien.nayrat@anayrat.info
> <mailto:adrien.nayrat@anayrat.info>> wrote:
>
>     Hello,
>
>     I noticed pg_dump failed to not dump creation or comment commands for public
>     schema when we explicitly ask it to dump public schema.
>
>     Shorter example: pg_dump -n public dump will give:
>
>  
>
>     [Create schema public....]
>
>  
> As far as I can tell this is working as intended/documented.  The public schema
> doesn’t and doesn’t and shouldn’t get special treatment relative to any other
> user schema here.
>

I am not sure. See this comment from selectDumpableNamespace:


That comment doesn't apply to this situation as it is attached to an if/else branch that doesn't handle the "-n" option case.
 
FYI this behavior appeared with pg11. With pg10 you won't have "CREATE SCHEMA
public" orders.

That matches what Tom said.
It is indeed a behavior change and the commit that caused it to change didn't change the documentation - so either the current behavior is a bug or the old documentation is wrong for failing to describe the old behavior sufficiently.

I stand by my comment that the current behavior and documentation agree - it doesn't call out any special behavior for the public schema being specified in "-n" and none is observed (now).

I'm tending to believe that the code benefits that resulted in this change are sufficient to keep new behavior as-is and not go back and introduce special public schema handling code to get it back to the way things were.  The public schema has issues and at this point the only reason it should exist and be populated in a database is for learning or quick debugging.  Its not worth breaking stuff to make that point more bluntly but if the natural evolution of the code results in people either adapting or abandoning the public schema I find that to be an acceptable price for progress.

David J.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Expand the use of check_canonical_path() for more GUCs
Next
From: Alvaro Herrera
Date:
Subject: Re: Expand the use of check_canonical_path() for more GUCs