Hello, thank you for taking the time for comment.
At Wed, 21 Dec 2011 11:09:59 -0500, Robert Haas wrote
> I find the names of the functions added here to be quite
> confusing and would suggest renaming them. I expected
> PQgetAsCstring to do something similar to PQgetvalue, but the
> code is com
On Thu, Dec 8, 2011 at 5:41 AM, Kyotaro HORIGUCHI
wrote:
> This is the patch to add the documentation of PGresult custom
> storage. It shows in section '31.19. Alternative result
> storage'.
It would be good to consolidate this into the main patch.
I find the names of the functions added here
Greg Smith writes:
> On 12/01/2011 05:48 AM, Kyotaro HORIGUCHI wrote:
>> xfer timePeak RSS
>> Original : 6.02s 850MB
>> libpq patch + Original dblink: 6.11s 850MB
>> full patch : 4.44s 643MB
> These look lik
On 12/01/2011 05:48 AM, Kyotaro HORIGUCHI wrote:
xfer time Peak RSS
Original: 6.02s 850MB
libpq patch + Original dblink : 6.11s 850MB
full patch : 4.44s 643MB
These look like interes
Hello,
The documentation had slipped my mind.
This is the patch to add the documentation of PGresult custom
storage. It shows in section '31.19. Alternative result
storage'.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/l
Ouch! I'm sorry for making a reverse patch for the first modification.
This is an amendment of the message below. The body text is
copied into this message.
http://archives.postgresql.org/message-id/20111201.192419.103527179.horiguchi.kyot...@oss.ntt.co.jp
===
Hello, This is the next version
Hello, This is the next version of Allow substitute allocators
for PGresult.
Totally chaning the concept from the previous one, this patch
allows libpq to handle alternative tuple store for received
tuples.
Design guidelines are shown below.
- No need to modify existing client code of libpq.
Hello,
me> I'll put further thought into dblink-plus taking it into
me> account.
..
me> Please let me have a little more time.
I've inquired the developer of dblink-plus about
RegisterResourceReleaseCallback(). He said that the function is
in bad compatibility with current implementation. In add
Hello,
At Fri, 11 Nov 2011 11:29:30 +0200, Heikki Linnakangas wrote
> You could use the resource owner mechanism to track
> them. Register a callback function with
> RegisterResourceReleaseCallback().
Thank you for letting me know about it. I have dug up a message
in pg-hackers refering to the me
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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.
Looking through the thread, I agree that it's a different thing than
w
On 12/11/2011 07:36, Robert Haas wrote:
On Sat, Nov 12, 2011 at 12:48 AM, Tom Lane wrote:
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
Heikki Linnakangas writes:
> On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
>> For these reasons, I propose to make allocators for PGresult
>> replaceable.
> You could use the resource owner mechanism to track them.
BTW, I just thought of a potentially fatal objection to making PGresult
allocatio
Kyotaro HORIGUCHI writes:
> Hello. This message is a proposal of a pair of patches that
> enables the memory allocator for PGresult in libpq to be
> replaced.
Since there seems to be rough consensus that something like this would
be a good idea, I looked more closely at the details of the patch.
On Sat, Nov 12, 2011 at 12:48 AM, Tom Lane wrote:
> 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 PGres
Stephen Frost writes:
> * Tom Lane (t...@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
* Tom Lane (t...@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 o
Heikki Linnakangas writes:
> On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
>> The comment at the the begging of pqexpbuffer.c says that libpq
>> should not rely on palloc(). Besides, Tom Lane said that palloc
>> should not be visible outside the backend(*1) and I agree with
>> it.
>>
>> *1: http:
On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
The comment at the the begging of pqexpbuffer.c says that libpq
should not rely on palloc(). Besides, Tom Lane said that palloc
should not be visible outside the backend(*1) and I agree with
it.
*1: http://archives.postgresql.org/pgsql-hackers/1999-0
Hello. This message is a proposal of a pair of patches that
enables the memory allocator for PGresult in libpq to be
replaced.
The comment at the the begging of pqexpbuffer.c says that libpq
should not rely on palloc(). Besides, Tom Lane said that palloc
should not be visible outside the backend(
19 matches
Mail list logo
