From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com> |
Cc: | 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>, Peter Smith <smithpb2250(at)gmail(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-17 08:44:06 |
Message-ID: | 84be7ff3-2763-4c0f-ac1e-ca9862077f41@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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. So adding a few more options in the future should
be fine. Compare pg_dump. I think this would make the help easier to
read, and incidentally also make the command-line tab completion more
functional.
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-06-17 08:55:06 | Re: Improve CRC32C performance on SSE4.2 |
Previous Message | Mats Kindahl | 2025-06-17 08:30:34 | Transactional behavior of pg_create_logical_replication_slot |