On 5/29/20 7:40 PM, David G. Johnston wrote:
>
>
> 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.
Yes, if it is expected it should me mentioned in release notes. As is, it is a
regression.
FYI, our continuous integration hit this issue: First we restore the schema and
then we apply migration step. We do this for every schema and this change broke
the initial restoration. It is weird that the restoration can fail on a clear
database.
>
> 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.
Excuse me, but there is no mention that public schema exists for learning or
quick debugging?
https://www.postgresql.org/docs/11/ddl-schemas.html
I am pretty sure most users use public schema and even postgres default database.
Regards,