From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Andrew Chernow <ac(at)esilo(dot)com>, Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavel Golub <pavel(at)microolap(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: fixing PQsetvalue() |
Date: | 2011-07-18 10:38:37 |
Message-ID: | 141800615.20110718133837@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, Merlin.
I hope it's OK that I've added Andrew's patch to CommitFest:
https://commitfest.postgresql.org/action/patch_view?id=606
I did this becuase beta3 already released, but nut nothig is done on
this bug.
You wrote:
MM> On Thu, Jun 23, 2011 at 7:54 AM, Andrew Chernow <ac(at)esilo(dot)com> wrote:
>>> you are creating as you iterate through. This behavior was
>>> unnecessary in terms of what libpqtypes and friends needed and may (as
>>> Tom suggested) come back to bite us at some point. As it turns out,
>>> PQsetvalue's operation on results that weren't created via
>>> PQmakeEmptyResult was totally busted because of the bug, so we have a
>>> unique opportunity to tinker with libpq here: you could argue that you
>>>
>>> +1
>>>
>>> Exactly at this moment I am thinking about using modifiable
>>> (via PQsetvalue) PGresult instead of std::map in my C++ library
>>> for store parameters for binding to executing command.
>>> I am already designed how to implement it, and I supposed that
>>> PQsetvalue is intended to work with any PGresult and not only
>>> with those which has been created via PQmakeEmptyResult...
>>> So, I am absolutely sure, that PQsetvalue should works with
>>> any PGresult.
>>
>> All PGresults are created via PQmakeEmptyPGresult, including libpqtypes.
>> Actually, libpqtypes calls PQcopyResult which calls PQmakeEmptyPGresult.
>>
>> It might be better to say a "server" result vs. a "client" result.
>> Currently, PQsetvalue is broken when provided a "server" generated result.
MM> er, right-- the divergence was in how the tuples were getting added --
MM> thanks for the clarification. essentially your attached patch fixes
MM> that divergence.
MM> merlin
--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-07-18 10:52:50 | Re: Re: [COMMITTERS] pgsql: Add temp_file_limit GUC parameter to constrain temporary file sp |
Previous Message | Pavel Golub | 2011-07-18 10:24:49 | Re: Error in PQsetvalue |