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

From Peter Smith
Subject Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date
Msg-id CAHut+PuPfi2KqXAcF1WvrhhtZ430LAy9vbFZqNC8maXjY=nH4g@mail.gmail.com
Whole thread Raw
In response to Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
List pgsql-hackers
On Sat, Mar 15, 2025 at 4:52 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Fri, Mar 14, 2025 at 5:39 PM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
> >
> > On Tuesday, March 11, 2025, Peter Smith <smithpb2250@gmail.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
justprovide 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
wasdone 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).

Does anyone else here have any preference about these styles they wish to voice?

>
> > Redefining All over the course of years as we decide to add object types is unappealing.  Even if we expect the DBA
tocheck the drop-commands.sql file before executing it.  Which I’d still require them to do instead of providing CLI
optionsto specify, e.g., slot names or database names to not drop if they want some subset of All. 
>

======
Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: how to see the generated nodetags.h
Next
From: Laurenz Albe
Date:
Subject: Re: Reducing the log spam