Tom Lane a396144ac0 Remove new coupling between NAMEDATALEN and MAX_LEVENSHTEIN_STRLEN. ... Commit e529cd4ffa introduced an Assert requiring NAMEDATALEN to be less than MAX_LEVENSHTEIN_STRLEN, which has been 255 for a long time. Since up to that instant we had always allowed NAMEDATALEN to be substantially more than that, this was ill-advised. It's debatable whether we need MAX_LEVENSHTEIN_STRLEN at all (versus putting a CHECK_FOR_INTERRUPTS into the loop), or whether it has to be so tight; but this patch takes the narrower approach of just not applying the MAX_LEVENSHTEIN_STRLEN limit to calls from the parser. Trusting the parser for this seems reasonable, first because the strings are limited to NAMEDATALEN which is unlikely to be hugely more than 256, and second because the maximum distance is tightly constrained by MAX_FUZZY_DISTANCE (though we'd forgotten to make use of that limit in one place). That means the cost is not really O(mn) but more like O(max(m,n)). Relaxing the limit for user-supplied calls is left for future research; given the lack of complaints to date, it doesn't seem very high priority. In passing, fix confusion between lengths-in-bytes and lengths-in-chars in comments and error messages. Per gripe from Kevin Day; solution suggested by Robert Haas. Back-patch to 9.5 where the unwanted restriction was introduced.		2016-01-22 11:53:06 -05:00
..
dmetaphone.c	pgindent run for 9.5	2015-05-23 21:35:49 -04:00
fuzzystrmatch--1.0.sql
fuzzystrmatch--unpackaged--1.0.sql
fuzzystrmatch.c	Remove new coupling between NAMEDATALEN and MAX_LEVENSHTEIN_STRLEN.	2016-01-22 11:53:06 -05:00
fuzzystrmatch.control
Makefile	Move the guts of our Levenshtein implementation into core.	2014-11-13 12:33:26 -05:00