Re: Error in PQsetvalue - Mailing list pgsql-hackers

From Pavel Golub
Subject Re: Error in PQsetvalue
Date
Msg-id 229879529.20110609084830@gf.microolap.com
Whole thread Raw
In response to Re: Error in PQsetvalue  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Error in PQsetvalue
List pgsql-hackers
Hello, Merlin.

You wrote:

MM> On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Merlin Moncure <mmoncure@gmail.com> writes:
>>> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Merlin Moncure <mmoncure@gmail.com> writes:
>>>>> I went ahead and tested andrew's second patch -- can we get this
>>>>> reviewed and committed?
>>
>>>> Add it to the upcoming commitfest.
>>
>>> It's a client crashing bug in PQsetvalue that goes back to 9.0 :(.
>>
>> I was under the impression that this was extending PQsetvalue to let it
>> be used in previously unsupported ways, ie, to modify a server-returned
>> PGresult.  That's a feature addition, not a bug fix.

MM> It's neither -- it's documented libpq behavior: "The function will
MM> automatically grow the result's internal tuples array as needed.
MM> However, the tup_num argument must be less than or equal to PQntuples,
MM> meaning this function can only grow the tuples array one tuple at a
MM> time. But any field of any existing tuple can be modified in any
MM> order. "

MM> Andrew was briefly flirting with a proposal to tweak this behavior,
MM> but withdrew the idea.

>> it's a feature addition I approve of.  I think serious consideration
>> ought to be given to locking down returned results so PQsetvalue refuses
>> to touch them, instead.  Otherwise we're likely to find ourselves unable
>> to make future optimizations because we have to support this
>> barely-used-by-anybody corner case.

Do I understand correctly that there is no any chance at all to have function
like PQdeleteTuple in libpq? (see my message "PQdeleteTuple
function in libpq" on Wed, 1 Jun 2011)

MM> I think that's debatable, but I'm not going to argue this yea or nea.
MM> But I will say that maybe we shouldn't confuse behavior issues with
MM> bug fix either way...patch the bug, and we can work up a patch to lock
MM> down the behavior and the docs if you want it that way, but maybe we
MM> could bikeshed a bit on that point.

MM> merlin



-- 
With best wishes,Pavel                          mailto:pavel@gf.microolap.com



pgsql-hackers by date:

Previous
From: Brar Piening
Date:
Subject: Re: smallserial / serial2
Next
From: Pavan Deolasee
Date:
Subject: Re: Autoanalyze and OldestXmin