Re: Should we add crc32 in libpgport?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Should we add crc32 in libpgport?
Дата
Msg-id 5149.1326778402@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Should we add crc32 in libpgport?  (Daniel Farina <daniel@heroku.com>)
Ответы Re: Should we add crc32 in libpgport?  (Daniel Farina <daniel@heroku.com>)
Список pgsql-hackers
Daniel Farina <daniel@heroku.com> writes:
> Copying CRC32 implementations everywhere is not the worst thing, but I
> find it inadequately explained why it's necessary for now, at least.

Agreed, but I don't care for your proposed solution (put it in
libpgport) because that assumes a fact not in evidence, namely that
external projects have access to libpgport either.

Is it possible to put enough stuff in pg_crc.h so that external code could
just include that, perhaps after an extra #define to enable extra code?
In the worst case we could just do
#ifdef PROVIDE_CRC_IMPLEMENTATION    ... current contents of pg_crc.c ...#endif

but perhaps there's some intermediate possibility that's less ugly.

As for whether we could drop the existing near-duplicate code in
contrib/, I think we'd first have to convince ourselves that it was
functionally identical, because otherwise replacing those versions would
break existing ltree and hstore indexes.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: WIP patch for parameterized inner paths
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Arithmetic operators for macaddr type