On Thu, Jul 17, 2014 at 9:34 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > Patch 1 does a couple of things: > - fuzzystrmatch is dumped to 1.1, as Levenshtein functions are not part of > it anymore, and moved to core. > - Removal of the LESS_EQUAL flag that made the original submission patch > harder to understand. All the Levenshtein functions wrap a single common > function. > - Documentation is moved, and regression tests for Levenshtein functions are > added. > - Functions with costs are renamed with a suffix with costs. > After hacking this feature, I came up with the conclusion that it would be > better for the user experience to move directly into backend code all the > Levenshtein functions, instead of only moving in the common wrapper as Peter > did in his original patches. This is done this way to avoid keeping portions > of the same feature in two different places of the code (backend with common > routine, fuzzystrmatch with levenshtein functions) and concentrate all the > logic in a single place. Now, we may as well consider renaming the > levenshtein functions into smarter names, like str_distance, and keep > fuzzystrmatch to 1.0, having the functions levenshteing_* calling only the > str_distance functions.
This is not cool. Anyone who is running a 9.4 or earlier database using fuzzystrmatch and upgrades, either via dump-and-restore or pg_upgrade, to a version with this patch applied will have a broken database. They will still have the catalog entries for the 1.0 definitions, but those definitions won't be resolvable inside the new cluster's .so file. The user will get a fairly-unfriendly error message that won't go away until they upgrade the extension, which may involve dealing with dependency hell since the new definitions are in a different place than the old definitions, and there may be dependencies on the old definitions. One of the great advantages of extension packaging is that this kind of problem is quite easily avoidable, so let's avoid it. There are several possible methods of doing that, but I think the best one is just to leave the SQL-callable C functions in fuzzystrmatch and move only the underlying code that supports into core. Then, the whole thing will be completely transparent to users. They won't need to upgrade their fuzzystrmatch definitions at all, and everything will just work; under the covers, the fuzzystrmatch code will now be calling into core code rather than to code located in that same module, but the user doesn't need to know or care about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
