Re: Doing better at HINTing an appropriate column within errorMissingColumn()
| От | Peter Geoghegan | 
|---|---|
| Тема | Re: Doing better at HINTing an appropriate column within errorMissingColumn() | 
| Дата | |
| Msg-id | CAM3SWZTyGk5s9LYJjABpBbjsUUXdoWc6Rq4H8xU01Z9Veegd8A@mail.gmail.com обсуждение исходный текст | 
| Ответ на | Re: Doing better at HINTing an appropriate column within errorMissingColumn() (Robert Haas <robertmhaas@gmail.com>) | 
| Ответы | Re: Doing better at HINTing an appropriate column within errorMissingColumn() | 
| Список | pgsql-hackers | 
On Wed, Nov 12, 2014 at 12:59 PM, Robert Haas <robertmhaas@gmail.com> wrote: > 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. Okay, thanks. I think I can do that fairly soon. > 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. Alright. It wasn't as if I felt very strongly about it either way. > 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. Sure. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: