Re: [PATCH] binary heap implementation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] binary heap implementation
Date: 2012-11-15 17:08:12
Message-ID: CA+TgmoaqwNKaZMXUd-LdvQmGsZkWpyCjnYBo_XwDZ-OHBWMvJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 15, 2012 at 11:50 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-11-15 17:13:06 Re: [PATCH 03/14] Add simple xlogdump tool
Previous Message Jeff Janes 2012-11-15 17:06:23 Re: [PATCH 03/14] Add simple xlogdump tool