Skip site navigation (1) Skip section navigation (2)

Re: Drop separate CRC32 implementations in ltree, tsearch,

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Drop separate CRC32 implementations in ltree, tsearch,
Date: 2005-06-02 06:46:44
Message-ID: 429EAB54.3020602@sigaev.ru (view raw or flat)
Thread:
Lists: 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(at)sigaev(dot)ru
                                                    WWW: http://www.sigaev.ru/

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-06-02 08:09:22
Subject: Re: lastval()
Previous:From: Oliver JowettDate: 2005-06-02 06:14:04
Subject: Re: NOLOGGING option, or ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group