Noah Misch wrote: > What exact formula did you have in mind? It must not be merely > > 1. "pg_dumpall -g" > 2. "pg_dump" (without --create) per database > > which _never_ works: it emits no CREATE DATABASE statements. Perhaps this? > > 1. "pg_dumpall -g" > 2. Issue a handwritten CREATE DATABASE statement per database with correct > encoding, lc_ctype and lc_collate parameters. All other database > properties can be wrong; the dump will fix them. > 3. "pg_dump" (without --create) per database > > That neglects numerous database properties today, but we could make it work. > Given the problems I described upthread, it's an inferior formula that I > recommend against propping up.
Agreed, and IMO it's embarrasing that it's so complicated to get a fully working backup. > I much prefer making this work completely: > > 1. "pg_dumpall -g" > 2. "pg_dump --create" per database My full support for this proposal. > Another formula I wouldn't mind offering: > > 1. "pg_dumpall -g" > 2. pg_dumpall --empty-databases > 3. "pg_dump" (without --create) per database > > Code for an --empty-databases option already exists for "pg_dumpall -g > --binary-upgrade". A patch turning that into a user-facing feature might be > quite compact. I don't mind if this one is also made to work, but I don't care about this case all that much. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
