public inbox for [email protected]
help / color / mirror / Atom feedFrom: Igor Korot <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: [GENERAL] Retrieving query results
Date: Tue, 16 Dec 2025 21:26:56 -0800
Message-ID: <CA+FnnTyR_0Xfs9E+3a-QYGqM4AmbMe2hYfYJbSiZpNZqoeSviQ@mail.gmail.com> (raw)
In-Reply-To: <CAB7nPqRnDMMKybjdC5fFd4XyDaE65UkMB2kAZ_NRm1T=AcZgCQ@mail.gmail.com>
References: <CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com>
<CAB7nPqTzPvrwDakXjogGCLZGfMpQO1AMWY3e3RMp7SsDGvdUSw@mail.gmail.com>
<[email protected]>
<CA+FnnTxaA2cuEQiMx4-XFwBX3mdFL5wRq_xcN_+chNM-HdQtYg@mail.gmail.com>
<[email protected]>
<CAB7nPqSE5voeA5LTDZ6PLkA4jNWuYB7nJJTaXRJBREH2LJE2Fg@mail.gmail.com>
<[email protected]>
<CAB7nPqR=zNbnsuX78TAuKa=3oZhuKn0JHR7ufvYfVcGdc7ZvyQ@mail.gmail.com>
<[email protected]>
<CAB7nPqRnDMMKybjdC5fFd4XyDaE65UkMB2kAZ_NRm1T=AcZgCQ@mail.gmail.com>
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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [GENERAL] Retrieving query results
In-Reply-To: <CA+FnnTyR_0Xfs9E+3a-QYGqM4AmbMe2hYfYJbSiZpNZqoeSviQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox