Re: Drop separate CRC32 implementations in ltree, tsearch,
От | Teodor Sigaev |
---|---|
Тема | Re: Drop separate CRC32 implementations in ltree, tsearch, |
Дата | |
Msg-id | 429EAB54.3020602@sigaev.ru обсуждение исходный текст |
Ответ на | Drop separate CRC32 implementations in ltree, tsearch, tsearch2? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> contrib/ltree, contrib/tsearch, and contrib/tsearch2 each contain > implementations of CRC32 calculations. I think these are now pretty > redundant with the CRC32 code existing in the main backend. They > use a different CRC polynomial than the main backend code does, > but it's hard to credit that that is an important difference. I think no matter. Although we had experiment to choice the best hash function and choose crc32. Other functions make much more collisions on non-engish words. > Anyone see a reason not to rip that code out and make these modules > use pg_crc.h/pg_crc.c instead? contrib/tsearch is already marked as obsolete, and I think that we can remove it away from contrib. BTW, ltree/crc32.c and tsearch2/crc32.c has small difference: ltree variant may lower string (depend of LOWER_NODE define) before calculation checksum. But pg_crc counts 64-bit checksum while contrib modules needs 32. Will be correct to use only half-value? I am afraid number of collisions will be more... -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-hackers по дате отправления: