On Sun, Nov 9, 2014 at 11:48 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Nov 7, 2014 at 12:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Based on this review from a month ago, I'm going to mark this Waiting
>> on Author. If nobody updates the patch in a few days, I'll mark it
>> Returned with Feedback. Thanks.
>
> Attached revision fixes the compiler warning that Heikki complained
> about. I maintain SQL-callable stub functions from within contrib,
> rather than follow Michael's approach. In other words, very little has
> changed from my revision from July last [1].
I agree with your proposed approach to moving Levenshtein into core.
However, I think this should be separated into two patches, one of
them moving the Levenshtein functionality into core, and the other
adding the new treatment for missing column errors. If you can do
that relatively soon, I'll make an effort to get the refactoring patch
committed in the near future. Once that's done, we can focus in on
the interesting part of the patch, which is the actual machinery for
suggesting alternatives.
On that topic, I think there's unanimous consensus against the design
where equally-distant matches are treated differently based on whether
they are in the same RTE or different RTEs. I think you need to
change that if you want to get anywhere with this. On a related note,
the use of the additional parameter AttrNumber closest[2] to
searchRangeTableForCol() and of the additional parameters AttrNumber
*matchedatt and int *distance to scanRTEForColumn() is less than
self-documenting. I suggest creating a structure called something
like FuzzyAttrMatchState and passing a pointer to it down to both
functions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
