Re: Allow substitute allocators for PGresult. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow substitute allocators for PGresult.
Date
Msg-id 19444.1321076906@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow substitute allocators for PGresult.  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Allow substitute allocators for PGresult.
Re: Allow substitute allocators for PGresult.
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Heikki's idea is probably superior so far as PG backend usage is
>> concerned in isolation, but I wonder if there are scenarios where a
>> client application would like to be able to manage libpq's allocations.

> The answer to that is certainly 'yes'.  It was one of the first things
> that I complained about when moving from Oracle to PG.  With OCI, you
> can bulk load results directly into application-allocated memory areas.

Well, loading data in a form whereby the application can access it
without going through the PGresult accessor functions would be an
entirely different (and vastly larger) project.  I'm not sure I want
to open that can of worms --- it seems like you could write a huge
amount of code trying to provide every format someone might want,
and still find that there were impedance mismatches for many
applications.

AIUI Kyotaro-san is just suggesting that the app should be able to
provide a substitute malloc function for use in allocating PGresult
space (and not, I think, anything else that libpq allocates internally).
Basically this would allow PGresults to be cleaned up with methods other
than calling PQclear on each one.  It wouldn't affect how you'd interact
with one while you had it.  That seems like pretty much exactly what we
want for preventing memory leaks in the backend; but is it going to be
useful for other apps?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Re: pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Next
From: Robert Haas
Date:
Subject: Re: Allow substitute allocators for PGresult.