Re: palloc unification

Tom Lane escribió:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On 6 February 2013 14:38, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >> Yeah, I am doing this right now and the "shared" name doesn't seem so
> >> good.  "libpgframework" sounds decent.  So since libpgport comes from
> >> src/port, are we okay with src/framework and src/include/framework?
>
> > "common" ?
>
> > src/backend/common
> > src/include/common
>
> To me the term "framework" carries a lot of baggage that doesn't fit
> this usage.  "common" seems better.

Okay, here's an attempt at doing it that way.  Notably this creates
libpgcommon, a static library, to be used by both frontend and backend.
There's only a frontend file now (fe_memutils.c); the backend side of it
is empty.  I verified that the backend makefile rules work, but there's
no attempt to link it into the backend.  libpgcommon piggybacks on
libpgport: for instance there is no separate submake-pgcommon rule on
which to depend, or LDFLAGS additions and the like, I just appended it
all to existing pgport rules.  Duplicating it would be much more verbose
and pointless; if we ever need to distinguish these two libs, that can
easily be done.

Some existing pg_malloc() implementations tried to do something other
than exit(EXIT_FAILURE); pg_upgrade did pg_log(FATAL) for instance.  But
I don't think there is much point in that, so I've just made them all
use fprintf(stderr); exit(EXIT_FAILURE);  This is the same approach
Zoltan ended up with in his patch.

MSVC is known broken (I didn't touch Andres' hunk of that.  I will look
into that later.)

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