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

From Gavin Flower
Subject Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date
Msg-id 53A0BE1E.4000207@archidevsys.co.nz
Whole thread Raw
In response to Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 18/06/14 10:05, Peter Geoghegan wrote:
> On Tue, Jun 17, 2014 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not proposing an immutable cutoff.  Something that scales with the
>> string length might be a good idea, or we could make it a multiple of
>> the minimum observed distance, or probably there are a dozen other things
>> we could do.  I'm just saying that if we have an alternative at distance
>> 3, and another one at distance 4, it's not clear to me that we should
>> assume that the first one is certainly what the user had in mind.
>> Especially not if all the other alternatives are distance 10 or more.
> The patch just looks for the match with the lowest distance, passing
> the lowest observed distance so far as a "max" to the distance
> calculation function. That could have some value in certain cases.
> People have already raised general concerns about added cycles and/or
> clutter.
>
How about a list of miss spellings and the likely targets.  (grop, grap, ...) ==> (grep, grape, grope...)
type of thing? Possibly with some kind of adaptive learning algorithm.

I suspect that while this might be a useful research project, it is out 
of scope for the current discussion!


Cheers,
Gavin



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Petr Jelinek
Date:
Subject: Re: Atomics hardware support table & supported architectures