Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. - Mailing list pgsql-hackers

On Tue, Jun 17, 2025 at 2:14 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> I have been trying to reconstruct how the new pg_createsubscriber option
> --remove/-R came about, specifically the name.  There was a dizzying
> number of messages in this thread about and around that, and in the end
> I don't think the solution is great at the moment.
>
> To recap, the first proposal was, as the subject says
>
> --clean-publisher-objects
>
> and then various other slightly reworded --clean-something variants were
> tossed around.
>
> Peter Smith raised the concern that "clean" is not an established term
> and it should by something based on "drop" instead.
>
> And then later, this was not entirely clear, I think it was changed to
> "remove" because there was no fitting short option available for "drop"?
>
> This seems like a backward way to design things, because the long
> options are supposed to be intuitive, and changing the intuitive thing
> so that the non-intuitive thing (the short option) is more intuitive, well.
>
> Another thing to consider is that the way things are going,
> pg_createsubscriber will have 60 command-line options in three years.
> So we're going to run out of short options.  Let's not try to cram new
> functionality into the existing letters just to use them up.  Let's keep
> the short options for the really important functionality.
>
> Also consider consistency with related tools.  Some people want to
> integrate pg_basebackup functionality into pg_createsubscriber.  It
> would make sense to be careful not to create confusing inconsistencies
> between the option sets of the two tools.
>
> Also, then why not "clean"?  "Clean" is certainly a more established
> term than "remove".  Look around initdb, pg_basebackup, pg_dump,
> pg_archivebackup for options named with that term.  There is no existing
> use of "remove".
>
> 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.

--
With Regards,
Amit Kapila.