Re: [PATCH] binary heap implementation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] binary heap implementation
Дата
Msg-id CA+TgmoaqwNKaZMXUd-LdvQmGsZkWpyCjnYBo_XwDZ-OHBWMvJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] binary heap implementation  (Andres Freund <andres@2ndquadrant.com>)
Ответы common fe/be library (was Re: [PATCH] binary heap implementation)  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Nov 15, 2012 at 11:50 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Me neither. I was thinking about letting the "user" allocate enough
> memory like:
>
> binaryheap *heap = palloc(binaryheap_size(/*capacity*/ 10));
> binaryheap_init(heap, 10, comparator);
>
> But thats pretty ugly.

Yeah.  I would vote against doing that for now.  We can always uglify
the code later if we decide it's absolutely necessary.

One trick that we could potentially use to make code run in the
frontend and backend is to put it in src/port.  That code gets
compiled twice, once within -DFRONTEND and once without.  So you can
use #ifdef to handle things that need to work different ways.  The
only real problem with that approach is that you end up putting the
code in libpgport where it seems rather out of place.  Still, maybe we
could have a src/framework directory that uses the same trick to
produce a libpgframework that frontend code can use, and a lib
pgframework_srv that can be linked into the backend.  That's might not
actually be that much work; we'd just need to clone all the existing
src/port logic.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [PATCH 03/14] Add simple xlogdump tool
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH 03/14] Add simple xlogdump tool