From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |
Date: | 2025-03-12 04:13:11 |
Message-ID: | CAKFQuwbH+xJmsvTTgKfnVu6B1SxNrpAge1pBjMCvsXgGDGbNhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday, March 11, 2025, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Tue, Mar 11, 2025 at 8:21 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Tue, Mar 11, 2025 at 12:20 AM Peter Smith <smithpb2250(at)gmail(dot)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".
> >
>
> Yes, this is a good idea, and IIRC, we discussed in brief on this in
> the original thread where we developed this tool but left it as a
> future improvement. We should definitely go in this direction in the
> future, but let's improve this tool incrementally, otherwise, there is
> a risk of making no improvements.
>
I’m against a UX that drops database objects selected by algorithm without
informing the user what those objects are and giving them a chance to
abort. The output file method makes that very simple to implement. I
think an interactive command to accomplish that requirement would put
commit more at risk. And a constant increase of options for each object
type seems annoying given the alternative of simply doing them all as we
get around to them and letting the file and the user remove the ones they
wish to keep.
I’m honestly question how much value this provides - no improvement here
seems like a viable choice. Let them issue the drop commands they desire
manually. This doesn’t feel like something one should/would automate.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-03-12 04:22:47 | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |
Previous Message | Amit Kapila | 2025-03-12 04:10:51 | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |