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

From Amit Kapila
Subject Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date
Msg-id CAA4eK1KFV8Uvy7vwJhQSU1t-=TWL1XC-pPL3VWcMFoditOfW-A@mail.gmail.com
Whole thread Raw
In response to Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
List pgsql-hackers
On Sat, Mar 15, 2025 at 8:03 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Friday, March 14, 2025, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>>
>> Style-1 sounds reasonable to me, but how exactly we want to do. One
>> idea is to have short and long switches like -r and
>> --remove_exiting_object=publication. The user would be allowed to give
>> multiple options like -r publications -r slots, etc.
>
>
> Either “existing” nor “object” are needed, a one-word long form suffices.  Drop, remove, or prune.  If we want a
shortform option we should choose Remove and use -r; both D and P are already taken. 
>
> So, I marginally prefer —prune with no short-form option; followed by —remove/-r
>

I am inclined towards "--remove/-r" as that will be relatively more
straightforward to follow for users.

> Communicating the semantic meaning of “prune” in the option name, we aren’t removing all objects of the given type,
tipsthe balance for me.  But that can just be communicated in the description so it isn’t a strong desire. 
>

BTW, with this option, we will be removing all the publications
present on the subscriber because on standby there shouldn't be any
more. But that may not be true for other objects, so we must
communicate it via the description.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PATCH: warn about, and deprecate, clear text passwords
Next
From: Isaac Morland
Date:
Subject: Re: TOAST versus toast