From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump fail to not dump public schema orders |
Date: | 2020-05-29 17:40:54 |
Message-ID: | CAKFQuwaOcYVrsELNiWceSt6o7uBZN5V1k3dzVdvak5gq5Cz9YQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 29, 2020 at 7:42 AM Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>
wrote:
> On 5/29/20 3:56 PM, David G. Johnston wrote:
> > On Friday, May 29, 2020, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info
> > <mailto:adrien(dot)nayrat(at)anayrat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-05-29 18:14:44 | Re: Expand the use of check_canonical_path() for more GUCs |
Previous Message | Robert Haas | 2020-05-29 17:24:27 | Re: Expand the use of check_canonical_path() for more GUCs |