I have been working with xlogdump and noticed that unfortunately it
cannot be installed without access to a postgres build directory,
which makes the exported functionality in src/include/utils/pg_crc.h
useless unless one has access to pg_crc.o -- which would only happen
if a build directory is lying around. Yet, pg_crc.h is *installed* in
server/utils, at least from my Debian package. Worse yet, those crc
implementations are the same but ever-so-slightly different (hopefully
in an entirely non-semantically-important way).
On more inspection, I also realized that the hstore and ltree contribs
*also* have crc32 implementations, dating back to 2006 and 2002,
respectively.
So I think the following actions might make sense:
* stop the distribution of pg_crc.h XOR include the crc tables into libpgport.a necessary to make them work
* Utilize the canonical pgport implementation of crc in both contribs
I tried my very best (mostly git log and reading the linked discussion
in the archives, as well as searching the archives) to find any
explanation why this is anything but an oversight that seems to
consistently result in less-desirable engineering in anything that is
compiled separately from Postgres but intends to link against it when
it comes to computing a CRC.
Copying CRC32 implementations everywhere is not the worst thing, but I
find it inadequately explained why it's necessary for now, at least.
--
fdr
