Re: palloc unification - Mailing list pgsql-hackers

On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> There was some discussion about unifying backend and frontend
> code/headers for palloc et al, particularly so that programs that want
> to mix both can be easily compiled; see
> http://www.postgresql.org/message-id/20130118150629.GC29501@alap2.anarazel.de
> for what I believe to be the latest and greatest patch in that area.
> The good news from that patch is that there is a reported (small)
> performance increase from the approach suggested there, on Intel and
> non-Intel platforms.  So it seems we're okay on that front.
>
> On the source code organization front, however, I'm not too happy with
> that particular proposal.  There would be two files named palloc.h, for
> one thing, and also the changes to utils/palloc.h leave way too much of
> the backend-only implementation exposed to the frontend world.
>
> I propose to have a new subdirectory src/include/shared, and two
> header files:
>
> src/include/utils/palloc.h (same as today)
> src/include/shared/fe_memutils.h
>         (pg_malloc, pg_free, pg_strdup decls)
>
> utils/palloc.h would be modified so that #ifdef FRONTEND, only the basic
> function declarations (palloc, pfree, pstrdup, pnstrdup) are exposed;
> frontend environment would be safe from CurrentMemoryContext etc.
>
> The frontend (pg_malloc) function definitions would live somewhere in,
> say, src/shared/fe_memutils.c.  For the palloc() implementation, I think
> we should create another file, so that frontend-only programs that do
> not require those symbols (most of them) are not unnecessarily bloated.
>
> Opinions on having a new subdir?
> We could eventually move some stuff from timestamp.c in there, so that
> pg_xlogdump could get timestamp_to_str from there; we could perhaps
> remove the ecpg implementation of that as well and make it use this one.

I like the idea of having a place for shared frontend and backend code
very much, but I don't think src/include/shared or src/shared is a
good name, because "shared" can mean a lot of things - like "shared
library", for example.  I think that this should be set up in a manner
analogous to libpgport, except not for portability code, but instead
for other stuff.  Maybe we could call it libpgframework or something.

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