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

From Peter Eisentraut
Subject Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date
Msg-id 84be7ff3-2763-4c0f-ac1e-ca9862077f41@eisentraut.org
Whole thread Raw
In response to Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.  (Amit Kapila <amit.kapila16@gmail.com>)
List 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.




pgsql-hackers by date:

Previous
From: Mats Kindahl
Date:
Subject: Transactional behavior of pg_create_logical_replication_slot
Next
From: John Naylor
Date:
Subject: Re: Improve CRC32C performance on SSE4.2