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

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date: 2025-06-18 05:49:07
Message-ID: CAHut+Ps1T_zJr4OeMhJH2Y7bSiRR2pM7fbS30-+DabQWVhYK1w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 18, 2025 at 2: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 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-06-18 05:58:57 Re: Allow pg_dump --statistics-only to dump foreign table statistics?
Previous Message Peter Eisentraut 2025-06-18 05:38:19 Re: minimum Meson version