On Fri, Mar 14, 2025 at 5:39 PM David G. Johnston
<david.g.johns...@gmail.com> wrote:
>
> On Tuesday, March 11, 2025, Peter Smith <smithpb2...@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 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
>

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 #2 because of
the potentially cumbersome length of the value part 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 to check the drop-commands.sql file 
> before executing it.  Which I’d still require them to do instead of providing 
> CLI options to specify, e.g., slot names or database names to not drop if 
> they want some subset of All.

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


Reply via email to