On Sun, Nov 9, 2014 at 11:48 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Fri, Nov 7, 2014 at 12:57 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
