On Tue, Nov 19, 2024 at 1:50 PM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote: > On Mon, Nov 18, 2024 at 08:29:10PM -0500, Corey Huinker wrote: > > That's not a great surprise for group 6, but I have to believe that group is > > smaller than group 5, and it's definitely smaller than the group of users that > > need to upgrade. > > Again, a clean API is the goal, not surprise calculus.
Maybe I was too harsh. "Surprise calculus" is fine, but only after we have an API that will be clearly understood by new users. We have to assume that in the long run new users will use this API more than existing users.
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?
