• Tom Lane's avatar
    Move handling of database properties from pg_dumpall into pg_dump. · b3f84012
    Tom Lane authored
    This patch rearranges the division of labor between pg_dump and pg_dumpall
    so that pg_dump itself handles all properties attached to a single
    database.  Notably, a database's ACL (GRANT/REVOKE status) and local GUC
    settings established by ALTER DATABASE SET and ALTER ROLE IN DATABASE SET
    can be dumped and restored by pg_dump.  This is a long-requested
    improvement.
    
    "pg_dumpall -g" will now produce only role- and tablespace-related output,
    nothing about individual databases.  The total output of a regular
    pg_dumpall run remains the same.
    
    pg_dump (or pg_restore) will restore database-level properties only when
    creating the target database with --create.  This applies not only to
    ACLs and GUCs but to the other database properties it already handled,
    that is database comments and security labels.  This is more consistent
    and useful, but does represent an incompatibility in the behavior seen
    without --create.
    
    (This change makes the proposed patch to have pg_dump use "COMMENT ON
    DATABASE CURRENT_DATABASE" unnecessary, since there is no case where
    the command is issued that we won't know the true name of the database.
    We might still want that patch as a feature in its own right, but pg_dump
    no longer needs it.)
    
    pg_dumpall with --clean will now drop and recreate the "postgres" and
    "template1" databases in the target cluster, allowing their locale and
    encoding settings to be changed if necessary, and providing a cleaner
    way to set nondefault tablespaces for them than we had before.  This
    means that such a script must now always be started in the "postgres"
    database; the order of drops and reconnects will not work otherwise.
    Without --clean, the script will not adjust any database-level properties
    of those two databases (including their comments, ACLs, and security
    labels, which it formerly would try to set).
    
    Another minor incompatibility is that the CREATE DATABASE commands in a
    pg_dumpall script will now always specify locale and encoding settings.
    Formerly those would be omitted if they matched the cluster's default.
    While that behavior had some usefulness in some migration scenarios,
    it also posed a significant hazard of unwanted locale/encoding changes.
    To migrate to another locale/encoding, it's now necessary to use pg_dump
    without --create to restore into a database with the desired settings.
    
    Commit 4bd371f6's hack to emit "SET default_transaction_read_only = off"
    is gone: we now dodge that problem by the expedient of not issuing ALTER
    DATABASE SET commands until after reconnecting to the target database.
    Therefore, such settings won't apply during the restore session.
    
    In passing, improve some shaky grammar in the docs, and add a note pointing
    out that pg_dumpall's output can't be expected to load without any errors.
    (Someday we might want to fix that, but this is not that patch.)
    
    Haribabu Kommi, reviewed at various times by Andreas Karlsson,
    Vaishnavi Prabakaran, and Robert Haas; further hacking by me.
    
    Discussion: https://postgr.es/m/CAJrrPGcUurV0eWTeXODwsOYFN=Ekq36t1s0YnFYUNzsmRfdAyA@mail.gmail.com
    b3f84012
pg_dump.c 551 KB