Re: pg_dump fail to not dump public schema orders

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: pg_dump fail to not dump public schema orders
Дата
Msg-id CAKFQuwaOcYVrsELNiWceSt6o7uBZN5V1k3dzVdvak5gq5Cz9YQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump fail to not dump public schema orders  (Adrien Nayrat <adrien.nayrat@anayrat.info>)
Ответы Re: pg_dump fail to not dump public schema orders  (Adrien Nayrat <adrien.nayrat@anayrat.info>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Expand the use of check_canonical_path() for more GUCs
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Expand the use of check_canonical_path() for more GUCs