Re: Add option --drop-cascade for pg_dump/restore

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add option --drop-cascade for pg_dump/restore
Date: 2021-05-28 18:39:09
Message-ID: 162222714927.1147.13089043546314690707.pgcf@coridan.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Overall the patch looks good, but I did notice a few small things:

1. In pg_dumpall.c, the section /* Add long options to the pg_dump argument list */, we are now
passing along the --drop-cascade option. However, --clean is not passed in, so
any call to pg_dumpall using --drop-cascade fails a the pg_dump step. You'll note
that --if-exists it not passed along either; because we are dropping the whole database, we don't
need to have pg_dump worry about dropping objects at all. So I think that
--drop-cascade should NOT be passed along from pg_dumpall to pg_dump.

2. I'm not even sure if --drop-cascade makes sense for pg_dumpall, as you cannot cascade global things like databases and roles.

3. In the file pg_backup_archiver.c, the patch does a
stmtEnd = strstr(mark + strlen(buffer), ";");" and then spits
out things "past" the semicolon as the final %s in the appendPQExpBuffer line.
I'm not clear why: are we expecting more things to appear after the semi-colon?
Why not just append a "\n" manually as part of the previous %s?

Cheers,
Greg

The new status of this patch is: Waiting on Author

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Gibson (DB Administrator) 2021-05-28 18:48:28 AWS forcing PG upgrade from v9.6 a disaster
Previous Message Mark Dilger 2021-05-28 17:42:21 Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)