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 <br...@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?"
