On 2025-07-17 Th 7:11 AM, Álvaro Herrera wrote:
On 2025-Jul-17, Mahendra Singh Thalor wrote:
To pg_restore, we are giving a dump of pg_dumpall which has a
global.dat file and we have drop commands in the global.dat file so
when we are using 'globals-only', we are dropping databases as we have
DROP commands.
As of now, we don't have any filter for global.dat file in restore. If
a user wants to restore only globals(without droping db), then they
should use 'globals-only' in pg_dumpall.
Or if we don't want to DROP databases by global.dat file, then we
should add a filter in pg_restore (hard to implement as we have SQL
commands in global.dat file).
I think dropping database is dangerous and makes no practical sense;
doing it renders pg_dumpall --clean completely unusable. You're arguing
from the point of view of ease of implementation, but that doesn't help
users.
Yeah. I also agree with Noah that we should be consistent with pg_dump.
And we should err on the side of caution. If we impose a little
inconvenience on the user by requiring them to drop a database, it's
better than surprising them by dropping a database when they didn't
expect it.
There are some subtleties here. pg_restore will only issue DROP DATABASE
of you use the -C flag, even if you specify --clean, so we need to be
very careful about issuing DROP DATABASE.
I confess that all this didn't occur to me when working on the commit.
I think, for this case, we can do some
more doc changes.
Example: pg_restore --globals-only : this will restore the global.dat
file(including all drop commands). It might drop databases if any drop
commands.
I don't think doc changes are useful.
Yeah, I don't think this is something that can be cured by documentation.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
