Re: Should we add crc32 in libpgport?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should we add crc32 in libpgport?
Date: 2012-01-17 05:33:22
Message-ID: 5149.1326778402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Farina <daniel(at)heroku(dot)com> writes:
> Copying CRC32 implementations everywhere is not the worst thing, but I
> find it inadequately explained why it's necessary for now, at least.

Agreed, but I don't care for your proposed solution (put it in
libpgport) because that assumes a fact not in evidence, namely that
external projects have access to libpgport either.

Is it possible to put enough stuff in pg_crc.h so that external code could
just include that, perhaps after an extra #define to enable extra code?
In the worst case we could just do

#ifdef PROVIDE_CRC_IMPLEMENTATION
... current contents of pg_crc.c ...
#endif

but perhaps there's some intermediate possibility that's less ugly.

As for whether we could drop the existing near-duplicate code in
contrib/, I think we'd first have to convince ourselves that it was
functionally identical, because otherwise replacing those versions would
break existing ltree and hstore indexes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-01-17 05:38:04 Re: Arithmetic operators for macaddr type
Previous Message Tom Lane 2012-01-17 05:06:54 WIP patch for parameterized inner paths