From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Igor Korot <ikorot01(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Improving overflow checks when adding tuple to PGresult Re: [GENERAL] Retrieving query results |
Date: | 2017-08-29 01:30:55 |
Message-ID: | CAB7nPqTnA3No2_B6x-QXPLHga1HatPqmXd03Xub+rPpshpmyMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Refactor-error-message-handling-in-pqAddTuple.patch | application/octet-stream | 4.9 KB |
0002-Improve-overflow-checks-of-pqAddTuple-in-libpq.patch | application/octet-stream | 2.1 KB |
pg_copy_res.c | text/x-csrc | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-29 01:31:58 | Re: Protect syscache from bloating with negative cache entries |
Previous Message | Masahiko Sawada | 2017-08-29 01:27:50 | Re: pgbench: Skipping the creating primary keys after initialization |