Thread: [HACKERS] Improving overflow checks when adding tuple to PGresult Re: [GENERAL]Retrieving query results
[HACKERS] Improving overflow checks when adding tuple to PGresult Re: [GENERAL]Retrieving query results
From
Michael Paquier
Date:
On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Attached are two patches: > 1) 0001 refactors the code around pqAddTuple to be able to handle > error messages and assign them in PQsetvalue particularly. > 2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the > size of what is allocated to INT_MAX but now more. > > pqRowProcessor() still has errmsgp, but it is never used on HEAD. At > least with this set of patches it comes to be useful. We could rework > check_field_number() to use as well an error message string, but I > have left that out to keep things simple. Not sure if any complication > is worth compared to just copying the error message in case of an > unmatching column number. As this change requires I think an extra lookup, I am moving the discussion to -hackers with a proper subject and the set of patches attached (and the test program). This patch is registered in the next commit fest. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Re: [HACKERS] Improving overflow checks when adding tuple to PGresult Re: [GENERAL] Retrieving query results
From
Tom Lane
Date:
Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> Attached are two patches:
>> 1) 0001 refactors the code around pqAddTuple to be able to handle
>> error messages and assign them in PQsetvalue particularly.
>> 2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the
>> size of what is allocated to INT_MAX but now more.
I've pushed these (as one commit) with some adjustments. Mainly,
I changed PQsetvalue to report failure messages with PQinternalNotice,
which is what already happens inside check_field_number() for the case
of an out-of-range field number. It's possible that storing the
message into the PGresult in addition would be worth doing, but I'm
unconvinced about that --- we certainly haven't had any field requests
for it.
regards, tom lane
Re: [HACKERS] Improving overflow checks when adding tuple to PGresultRe: [GENERAL] Retrieving query results
From
Michael Paquier
Date:
On Wed, Aug 30, 2017 at 4:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >>> Attached are two patches: >>> 1) 0001 refactors the code around pqAddTuple to be able to handle >>> error messages and assign them in PQsetvalue particularly. >>> 2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the >>> size of what is allocated to INT_MAX but now more. > > I've pushed these (as one commit) with some adjustments. Thanks! > Mainly, > I changed PQsetvalue to report failure messages with PQinternalNotice, > which is what already happens inside check_field_number() for the case > of an out-of-range field number. It's possible that storing the > message into the PGresult in addition would be worth doing, but I'm > unconvinced about that --- we certainly haven't had any field requests > for it. OK, fine for me. -- Michael