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
