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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
