Re: Doing better at HINTing an appropriate column within errorMissingColumn()
От | Alvaro Herrera |
---|---|
Тема | Re: Doing better at HINTing an appropriate column within errorMissingColumn() |
Дата | |
Msg-id | 20140723201019.GC5475@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Doing better at HINTing an appropriate column within errorMissingColumn() (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Doing better at HINTing an appropriate column within errorMissingColumn()
|
Список | pgsql-hackers |
Peter Geoghegan wrote: > For some reason I thought that that was what Michael was proposing - a > more comprehensive move of code into core than the structuring that I > proposed. I actually thought about a Levenshtein distance operator at > one point months ago, before I entirely gave up on that. The > MAX_LEVENSHTEIN_STRLEN limitation made me think that the Levenshtein > distance functions are not suitable for core as is (although that > doesn't matter for my purposes, since all I need is something that > accommodates NAMEDATALEN sized strings). MAX_LEVENSHTEIN_STRLEN is a > considerable limitation for an in-core feature. I didn't get around to > forming an opinion on how and if that should be fixed. I had two thoughts: 1. Should we consider making levenshtein available to frontend programs as well as backend? 2. Would it provide better matching to use Damerau-Levenshtein[1] instead of raw Levenshtein? .oO(Would anyone be so bold as to attempt to implement bitap[2] using bitmapsets ...) [1] http://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance [2] http://en.wikipedia.org/wiki/Bitap_algorithm -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: