On Wed, Nov 27, 2024 at 09:18:45AM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 04:00:02PM +0100, Alvaro Herrera wrote:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >
> >> On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
> >> > If you want to avoid both the surprise and confusion factor mentioned before,
> >> > maybe what's needed is to *remove* --analyze-in-stages, and replace it with
> >> > --analyze-missing-in-stages and --analyze-all-in-stages (with the clear warning
> >> > about what --analyze-all-in-stages can do to your system if you already have
> >> > statistics).
> >> >
> >> > That goes with the "immediate breakage that you see right away is better than
> >> > silently doing the unexpected where you might not notice the problem until much
> >> > later".
> >> >
> >> > That might trade some of that surprise and confusion for annoyance instead, but
> >> > going forward that might be a clearer path?
> >>
> >> Oh, so remove --analyze-in-stages and have it issue a suggestion, and
> >> make two versions --- yeah, that would work too.
>
> We did something similar when we removed exclusive backup mode.
> pg_start_backup() and pg_stop_backup() were renamed to pg_backup_start()
> and pg_backup_stop() to prevent folks' backup scripts from silently
> changing behavior after an upgrade.
>
> > Maybe not remove the option, but add a required parameter:
> > --analyze-in-stages=all / missing
> >
> > That way, if the option is missing, the user can adapt the command line
> > according to need.
>
> I like this idea.
Uh, do we have parameters that require a boolean option like this?
Would there be a default?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"