Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

On Tuesday, March 11, 2025, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:

>
> Choice 3. Implement some option that has an argument saying what to delete
>
> Implement an option that takes some argument saying what objects to remove.
>
> Here, the current patch would be something like:
> "--remove-target-objects=publications". In future, this option could
> be enhanced to accept other values like
> "--remove-target-objects=publications,subscriptions" etc.
>

I’m changing my vote to option 3. With a requirement that dropping is done
post-recovery by the user via psql - we just provide the commands we would
have executed in a script.

—prune-file=‘drop-commands.psql’
—prune=publications
—prune=subscriptions
Etc…

I’d rather do multiple specifications than commas separated. It matches
what we already do with databases, which was done this way I suspect for
the same reasons - length of the parameters value when we have:
Publications
Slots
Subscriptions
Databases
Roles
Tablespaces

Redefining All over the course of years as we decide to add object types is
unappealing. Even if we expect the DBA to check the drop-commands.sql file
before executing it. Which I’d still require them to do instead of
providing CLI options to specify, e.g., slot names or database names to not
drop if they want some subset of All.

David J.