Re: [GENERAL] Retrieving query results

Hi, ALL,

On Sun, Aug 27, 2017 at 11:05 PM Michael Paquier
<michael.paquier@gmail.com> wrote:
>
> On Sun, Aug 27, 2017 at 12:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Michael Paquier <michael.paquier@gmail.com> writes:
> >> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <tgl@sss.pgh.pa.us> 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