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