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.
Anyone see a reason not to rip that code out and make these modules
use pg_crc.h/pg_crc.c instead?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> 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/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly