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

On Tue, Jun 17, 2025 at 9:22 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Tue, Jun 17, 2025 at 2:14 PM Peter Eisentraut <peter(at)eisentraut(dot)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.
>

--clean works for me. I like the pg_basebackup precedence here.

> > 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.
> >
>

This would be nice to publish as design guidelines somewhere. I concur.

> 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.
>
>
--verb-objecttype=pattern ? (*.* could stand in for all)

The longer this list becomes the less appealing making it simple to type in
being a desire is. It's going to end up copy-paste anyway. Or an
interactive tool...

David J.