pgsql: Fix pg_dump's handling of public schema with both -c and -C opti - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix pg_dump's handling of public schema with both -c and -C opti
Date
Msg-id E1bUctg-0003x5-OM@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix pg_dump's handling of public schema with both -c and -C options.

Since -c plus -C requests dropping and recreating the target database
as a whole, not dropping individual objects in it, we should assume that
the public schema already exists and need not be created.  The previous
coding considered only the state of the -c option, so it would emit
"CREATE SCHEMA public" anyway, leading to an unexpected error in restore.

Back-patch to 9.2.  Older versions did not accept -c with -C so the
issue doesn't arise there.  (The logic being patched here dates to 8.0,
cf commit 2193121fa, so it's not really wrong that it didn't consider
the case at the time.)

Note that versions before 9.6 will still attempt to emit REVOKE/GRANT
on the public schema; but that happens without -c/-C too, and doesn't
seem to be the focus of this complaint.  I considered extending this
stanza to also skip the public schema's ACL, but that would be a
misfeature, as it'd break cases where users intentionally changed that
ACL.  The real fix for this aspect is Stephen Frost's work to not dump
built-in ACLs, and that's not going to get back-ported.

Per bugs #13804 and #14271.  Solution found by David Johnston and later
rediscovered by me.

Report: <20151207163520.2628.95990@wrigleys.postgresql.org>
Report: <20160801021955.1430.47434@wrigleys.postgresql.org>

Branch
------
REL9_2_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/a5a7caaa1b5c6a00ee3fb891cd330cce862e33b7

Modified Files
--------------
src/bin/pg_dump/pg_backup_archiver.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Fix pg_dump's handling of public schema with both -c and -C opti
Next
From: Peter Eisentraut
Date:
Subject: pgsql: Change minimum max_worker_processes from 1 to 0