Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=co6ZGujV340_n9-4NDviYxT_HLvPQBbfoZnO41kR1nRg@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Robert Treat <rob@xzilla.net>)
Responses Re: Statistics Import and Export
List pgsql-hackers
Until we add a fourth option, and then it becomes completely ambiguous as to whether you wanted data+statstics, or you not-wanted schema.


except it is perfectly clear that you *asked for* data and statistics, so you get what you asked for. however the user conjures in their heads what they are looking for, the logic is simple, you get what you asked for. 

They *asked for* that because they didn't have the mechanism to say "hold the mayo" or "everything except pickles". That's reducing their choice, and then blaming them for their choice.

In the UX world, the general pattern is people start to get overwhelmed once you get over a 1/2 dozen options (I think that's based on Miller's law, but might be mis-remembering); we are already at 9 for this use case. So really it is quite the opposite, we'd be reducing the burden on customers by simplifying the interface rather than just throwing out every possible combination and saying "you figure it out".

Except that those options are easily grouped into families. I see that there's a --no-comments flag, so why wouldn't there be a --no-statistics flag? Lots of $thing have a --no-$thing. That's the established UX pattern _working_. The user learned that pattern and we shouldn't punish them by changing it for our own parsing convenience.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg16 && GSSAPI && Heimdal/Macos
Next
From: Nathan Bossart
Date:
Subject: Re: doc: expand note about pg_upgrade's --jobs option