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

On Wed, Jun 18, 2025 at 2:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.
>

My original comment was only considering the resulting action so at
the time I felt "cleaning" publications made less sense to me than
just saying what was really happening ("dropping" the publications).

But I was not taking into account any precedent from other command
option names. So if "clean" is already a precedent, then I am fine
with calling this option clean too.

======
Kind Regards,
Peter Smith.
Fujitsu Australia.