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

From Tom Lane
Subject Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date
Msg-id 13379.1403038751@sss.pgh.pa.us
Whole thread Raw
In response to Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Kevin Grittner <kgrittn@ymail.com>)
Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 17, 2014 at 12:51 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> I disagree. I happen to think that making some guess is better than no
>> guess at all here, given the fact that there aren't too many
>> possibilities to choose from.

> Emitting a suggestion with a large distance seems like it could be
> rather irritating.  If the user types in SELECT prodct_id FROM orders,
> and that column does not exist, suggesting "product_id", if such a
> column exists, will likely be well-received.  Suggesting a column
> named, say, "price", however, will likely make at least some users say
> "no I didn't mean that you stupid @%!#" - because probably the issue
> there is that the user selected from the completely wrong table,
> rather than getting 6 of the 9 characters they typed incorrect.

Yeah, that's my point exactly.  There's no very good reason to assume that
the intended answer is in fact among the set of column names we can see;
and if it *is* there, the Levenshtein distance to it isn't going to be
all that large.  I think that suggesting "foobar" when the user typed
"glorp" is not only not helpful, but makes us look like idiots.

> One existing tool that does something along these lines is 'git',
> which seems to have some kind of a heuristic to know when to give up:

I wouldn't necessarily hold up git as a model of user interface
engineering ;-) ... but still, it might be interesting to take a look
at exactly what heuristics they used here.  I'm sure there are other
precedents we could look at, too.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Built-in support for a memory consumption ulimit?
Next
From: Peter Geoghegan
Date:
Subject: Re: btreecheck extension