On Tue, Mar 11, 2025 at 12:20 AM Peter Smith <smithpb2...@gmail.com> wrote:
> > Unfortunately, we are spinning in circles a bit trying to come up with > a good way to represent the option needed for this, while at the same > time trying to be future-proof. I see 3 choices... > > ====== > > Choice 1. Generic option > > Implement a single boolean option to remove everything. > > > Do you have any thoughts on what kind of option is best here? > > Option 1 by far. Though personally I'd rather do something like what pg_upgrade does and output a script with drop commands that can be executed via psql instead of having pg_createsubscriber execute said commands. I'd call it "pruning the target". Any automated bash script I'd write would just do: pg_createsubscriber ... --prune-target-script=prune.sql psql --file prune.sql And if I'm working interactively I'd want to spend the extra minute or so reviewing the commands in prune.sql to make sure I know what is going away. I can also edit said file, or use something like grep, if I want to limit what is dropped. In particular any database that isn't turned into a logical replica would be added to this list; in addition to all the publication/subscription stuff that is likely broken at this point. David J.
