Re: Should we add crc32 in libpgport?

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: Should we add crc32 in libpgport?
Дата
Msg-id CAAZKuFYv0cDt-3gcBcG97p8ShTP-sNn=H9aAGQivHsRjsC8D8w@mail.gmail.com
обсуждение исходный текст
Ответ на Should we add crc32 in libpgport?  (Daniel Farina <daniel@heroku.com>)
Ответы Re: Should we add crc32 in libpgport?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Farina
Дата:
Сообщение: Re: Review of: pg_stat_statements with query tree normalization
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Why is CF 2011-11 still listed as "In Progress"?