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

On Tue, Jun 17, 2025 at 2:14 PM Peter Eisentraut <peter@eisentraut.org> wrote:

> I'm also suggesting that "clean" or "cleanup" may be even better than
> "drop".  Because if you look at related tools such as pg_basebackup,
> pg_receivewal, etc., the "create" and "drop" actions all happen on the
> remote instance, but what we are talking about here happens on the local
> (new) instance, so a slightly different term from those might be
> appropriate.  Moreover, "clean(up)" has a connotation "don't need it
> anymore", which is fitting for this.
>

I am fine with changing the name to "clean" or "cleanup" as it has
some precedence as well but would like to see if Peter or David has
any opinion on this, as they were previously involved in naming this
option.

> Finally, I'm not a fan of this
>
> --verb=objecttype
>
> option naming (that is, currently, --remove=publications).  In contexts
> like this, the argument of the option is usually a name or a name
> pattern.  (What if you want something like that in the future?)  There
> is nothing wrong in my opinion with having a few --verb-objecttype
> options and adding a few more.  There was discussion about leaving room
> for future expansion, but I've only found one or two suggestions about
> what might be needed.
>

The list can be longer than one or two. We may need to provide similar
options for other objects, such as replication slots (synced failover
replication slots on the physical standby), user-defined functions,
triggers, views, materialized views, operators, policies, etc. And
then, we would also need 'all' kind of additional option to allow
cleaning all such objects. The newly formed subscriber may need a few
of the objects that got replicated on the prior physical standby to
operate, but not all.