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

On Friday, March 14, 2025, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Sat, Mar 15, 2025 at 11:35 AM Peter Smith <smithpb2250(at)gmail(dot)com>
> wrote:
> >
> > On Sat, Mar 15, 2025 at 4:52 PM Peter Smith <smithpb2250(at)gmail(dot)com>
> wrote:
> > >
> > > On Fri, Mar 14, 2025 at 5:39 PM David G. Johnston
> > > <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > > >
> > > > On Tuesday, March 11, 2025, Peter Smith <smithpb2250(at)gmail(dot)com>
> wrote:
> > > >>
> > > >>
> > > >> Choice 3. Implement some option that has an argument saying what to
> delete
> > > >>
> > > >> Implement an option that takes some argument saying what objects to
> remove.
> > > >>
> > > >> Here, the current patch would be something like:
> > > >> "--remove-target-objects=publications". In future, this option
> could
> > > >> be enhanced to accept other values like
> > > >> "--remove-target-objects=publications,subscriptions" etc.
> > > >
> > > >
> > > > I’m changing my vote to option 3. With a requirement that dropping
> is done post-recovery by the user via psql - we just provide the commands
> we would have executed in a script.
> > > >
> > > > —prune-file=‘drop-commands.psql’
> > > > —prune=publications
> > > > —prune=subscriptions
> > > > Etc…
> > > >
> > > > I’d rather do multiple specifications than commas separated. It
> matches what we already do with databases, which was done this way I
> suspect for the same reasons - length of the parameters value when we have:
> > > > Publications
> > > > Slots
> > > > Subscriptions
> > > > Databases
> > > > Roles
> > > > Tablespaces
> > > >
> > >
> >
> > (I'm sorry, my previous post included a confusing typo. Here is the
> correction)
> >
> > OK. Here are some examples...
> >
> > style #1:
> > --prune=Publications --prune=Slots --prune=Subscriptions
> > --prune=Databases --prune=Tablespaces
> >
> > versus
> >
> > style #2:
> > --prune=Publications,Slots,Subscriptions,Databases,Tablespaces
> >
> > David, I understand you are saying that you prefer style #1 because of
> > the potentially cumbersome length of the csv value part of style #2 if
> > there are many future object kinds (e.g.
> > "Publications,Slots,Subscriptions,Databases,Tablespaces" in the above
> > examples).
> >
>
> 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 short form 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

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

David J.