Re: Should we add crc32 in libpgport?
От | Robert Haas |
---|---|
Тема | Re: Should we add crc32 in libpgport? |
Дата | |
Msg-id | CA+TgmoYW1uAdNttH=Hos29+QtHwC-5jeVgFArSHGR_OV11dkbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we add crc32 in libpgport? (Daniel Farina <daniel@heroku.com>) |
Ответы |
Re: Should we add crc32 in libpgport?
|
Список | pgsql-hackers |
On Mon, Jan 16, 2012 at 8:09 PM, Daniel Farina <daniel@heroku.com> wrote: > 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. I think you make a compelling case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: