Re: Should we add crc32 in libpgport? - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Should we add crc32 in libpgport?
Date
Msg-id CAAZKuFYv0cDt-3gcBcG97p8ShTP-sNn=H9aAGQivHsRjsC8D8w@mail.gmail.com
Whole thread Raw
In response to Should we add crc32 in libpgport?  (Daniel Farina <daniel@heroku.com>)
Responses Re: Should we add crc32 in libpgport?
List pgsql-hackers
On Mon, Jan 16, 2012 at 4:56 PM, Daniel Farina <daniel@heroku.com> wrote:
> 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).

Out-of-order editing snafu.  "Worse yet, those crc implementations are
the..."  should come after the note about there being two additional
crc implementations in the postgres contribs.

Looking back on it, it's obvious why those contribs had it in the
first place: because they started external, and needed CRC, and the
most expedient thing to do is include yet another implementation.  So
arguably this problem has occurred three times: in xlogdump, and in
pre-contrib versions of hstore, and ltree.  It's just the latter two
sort of get a free pass by the virtue of having access to the postgres
build directory as contribs in this day and age.

--
fdr


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: Review of: pg_stat_statements with query tree normalization
Next
From: Robert Haas
Date:
Subject: Re: Why is CF 2011-11 still listed as "In Progress"?