palloc unification

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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services