Re: [PATCH] binary heap implementation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] binary heap implementation
Date
Msg-id CA+TgmoaqwNKaZMXUd-LdvQmGsZkWpyCjnYBo_XwDZ-OHBWMvJg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] binary heap implementation  (Andres Freund <andres@2ndquadrant.com>)
Responses common fe/be library (was Re: [PATCH] binary heap implementation)  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [PATCH 03/14] Add simple xlogdump tool
Next
From: Andres Freund
Date:
Subject: Re: [PATCH 03/14] Add simple xlogdump tool