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