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 13601.1416499532@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()  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> ... 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.

FWIW, I concur with Robert's analysis that wrong suggestions are likely to
be annoying.  We should be erring on the side of not making a suggestion
rather than making one that's a low-probability guess.

I'm not particularly convinced that the "f1" -> "f2" example is a useful
behavior, and I'm downright horrified by the "qty" -> "quantity" case.
If the hint mechanism thinks the latter two are close enough together
to suggest, it's going to be spewing a whole lot of utterly ridiculous
suggestions.  I'm going to be annoyed way more times than I'm going to
be helped.

The big picture is that this is more or less our first venture into
heuristic suggestions.  I think we should start slow with a very
conservative set of heuristics.  If it's a success maybe we can get more
aggressive over time --- but if we go over the top here, the entire
concept will be discredited in this community for the next ten years.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_multixact not getting truncated
Next
From: Robert Haas
Date:
Subject: Re: On partitioning