Hi, ALL, On Sun, Aug 27, 2017 at 11:05 PM Michael Paquier <[email protected]> wrote: > > On Sun, Aug 27, 2017 at 12:12 AM, Tom Lane <[email protected]> wrote: > > Michael Paquier <[email protected]> writes: > >> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <[email protected]> wrote: > >>> I think the real problem occurs where we realloc the array bigger. > > > >> Looking at the surroundings, I think that it would be nice to have > >> pqAddTuple and PQsetvalue set an error message with this patch. > > > > Yeah, I was thinking about that myself - the existing design presumes > > that the only possible reason for failure of pqAddTuple is OOM, but > > it'd be better to distinguish "too many tuples" from true OOM. So > > we should also refactor to make pqAddTuple responsible for setting > > the error message. Might be best to do the refactoring first. > > 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. > > Attached is as well a small program I have used to test PQsetvalue > through PQcopyResult to see if results get correctly allocated at each > call, looking at the error message stacks on the way.
Is this now part of the main libpq codebase? Thank you. > -- > Michael
