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

Should we add crc32 in libpgport?

From: Daniel Farina <daniel(at)heroku(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Should we add crc32 in libpgport?
Date: 2012-01-17 00:56:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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,

So I think the following actions might make sense:

* stop the distribution of pg_crc.h
  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.



pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-01-17 00:57:55
Subject: Re: Review of: pg_stat_statements with query tree normalization
Previous:From: Scott MeadDate: 2012-01-17 00:43:33
Subject: Re: IDLE in transaction introspection

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