Re: Doing better at HINTing an appropriate column within errorMissingColumn() - Mailing list pgsql-hackers

On Wed, Nov 19, 2014 at 2:33 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I don't think that's the case. Other RTEs are penalized for having
> non-matching aliases here.

The point I made did not, as far as I can see, have anything to do
with non-matching aliases; it could arise with just a single RTE.

> In general, I think the cost of a bad suggestion is much lower than
> the benefit of a good one. You seem to be suggesting that they're
> equal. Or that they're equally likely in an organic situation. In my
> estimation, this is not the case at all.

The way I see it, the main cost of a bad suggestion is that it annoys
the user with clutter which they may brand as "stupid".  Think about
how much vitriol has been spewed over the years against progress bars
(or estimated completion) times that don't turn out to mirror reality.
Microsoft has gotten more cumulative flack about their inaccurate
progress bars over the years than they would have for dropping an
elevator on a cute baby.  Or think about how annoying it is when a
spell-checker or grammar-checker underlines something you've written
that is, in your own opinion, correctly spelled or grammatical.  Maybe
that kind of thing doesn't annoy you, but it definitely annoys me, and
I think probably a lot of other people.  My general experience is that
people get quite pissed off by bad suggestions from a computer.  At
least in my experience, users' actual level of agitation is often all
out of proportion to what might seem justified, but we are designing
this software for actual users, so their likely emotional reactions
are relevant.

> I'm curious about your thoughts on the compromise of a ramped up
> distance threshold to apply a test for the absolute quality of a
> match. I think that the fact that git gives bad suggestions with terse
> strings tells us a lot, though. Note that unlike git, with terse
> strings we may well have a good deal more equidistant matches, and as
> soon as the number of would-be matches exceeds 2, we actually give no
> matches at all. So that's an additional protection against poor
> matches with terse strings.

I don't know what you mean by a ramped-up distance threshold, exactly.
I think it's good for the distance threshold to be lower for small
strings and higher for large ones.  I think I'm somewhat open to
negotiation on the details, but I think any system that's going to
suggest "quantity" for "tit" is going too far.  If the user types
"qty" when they meant "quantity", they probably don't really need the
hint, because they're going to say to themselves "wait, I guess I
didn't abbreviate that".  The time when they need the hint is when
they typed "quanttiy", because it's quite possible to read a query
with that sort of typo multiple times and not realize that you've made
one.  You're sitting there puzzling over where the quantity column
went, and asking yourselves how you can be mis-remembering the schema,
and saying "wait, didn't I just see that column in the \d output" ...
and you don't even think to check carefully for a spelling mistake.
The hint may well clue you in to what the real problem is.

In other words, I think there's value in trying to clue somebody in
when they've made a typo, but not when they've made a think-o.  We
won't be able to do the latter accurately enough to make it more
useful than annoying.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company