[PATCH] Factor out pg_malloc and friends into port code - Mailing list pgsql-hackers

On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan <zb@cybertec.at> wrote:

2013-01-02 01:24 keltezéssel, Tom Lane írta:

Boszormenyi Zoltan <zb@cybertec.at> writes:

2013-01-01 17:18 keltezéssel, Magnus Hagander írta:

That way we can get around the whole need for changing memory allocation across all the
frontends, no? Like the attached.

Sure it's simpler but then the consistent look of the code is lost.
What about the other patch to unify pg_malloc and friends?
Basically all client code boils down to
      fprintf(stderr, ...)
in different disguise in their error reporting, so that patch can
also be simplified but it seems that the atexit() - either explicitly
or hidden behind InitPostgresFrontend() - cannot be avoided.

Meh.  I find it seriously wrongheaded that something as minor as an
escape_quotes() function should get to dictate both malloc wrappers
and error recovery handling throughout every program that might use it.

Actually, the unification of pg_malloc and friends wasn't dictated
by this little code, it was just that pg_basebackup doesn't provide
a pg_malloc implementation (only pg_malloc0) that is used by
initdb's escape_quotes() function. Then I noticed how wide these
almost identical functions have spread into client apps already.

I would say this unification patch is completely orthogonal to
the patch in $SUBJECT. I will post it in a different thread if it's
wanted at all. The extra atexit() handler is not needed if a simple
fprintf(stderr, ...) error reporting is enough in all clients.
As far as I saw, all clients do exactly this but some of them hide
this behind #define's.

Please do keep that one separate - let's avoid unnecessary feature-creep, whether it's good or bad features.

The patch is attached. There is no extra atexit() code in this one.

I did this over my pg_basebackup patch, there are two chunks
that gets rejected if applied without it: one in initdb.c, the other is
in src/port/Makefile. It's because the modified codes are too close
to each other.

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de    http://www.postgresql.at/