From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | [pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) instead of "Pg... |
Date: | 2018-01-02 18:58:29 |
Message-ID: | 5a4bd6554474f_7aa82b0b24a15c0c76385@hookshot-fe-cace476.cp1-iad.github.net.mail |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Branch: refs/heads/master
Home: https://github.com/pgjdbc/pgjdbc
Commit: 0d31d46adff4e9772db843195e1638531bc703e0
https://github.com/pgjdbc/pgjdbc/commit/0d31d46adff4e9772db843195e1638531bc703e0
Author: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Date: 2018-01-02 (Tue, 02 Jan 2018)
Changed paths:
M pgjdbc/src/main/java/org/postgresql/core/v3/QueryExecutorImpl.java
M pgjdbc/src/test/java/org/postgresql/test/jdbc3/GeneratedKeysTest.java
Log Message:
-----------
fix: throw TOO_MANY_RESULTS (0100E) instead of "PgResultSet: tuples must be non-null"
When expecting no rows (e.g. executeUpdate with NO_GENERATED_KEYS) a query might still return one row
as "max rows" in Execute message does not allow to limit the resultset completely.
The returned tuples are ignored all the way up via "noResults / QueryExecutor.QUERY_NO_RESULTS", however
it fails when it meets handler.handleResultRows and tries to create a resultSet.
The corrective action is to create empty tuples list so empty resultSet is created.
The issue is reproduced in binary=FORCE in GeneratedKeysTest
Commit: 082d00941ad5f8abf44a0785a6f086c106b3c746
https://github.com/pgjdbc/pgjdbc/commit/082d00941ad5f8abf44a0785a6f086c106b3c746
Author: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Date: 2018-01-02 (Tue, 02 Jan 2018)
Changed paths:
M pgjdbc/src/main/java/org/postgresql/core/v3/QueryExecutorImpl.java
M pgjdbc/src/main/java/org/postgresql/util/PSQLState.java
M pgjdbc/src/test/java/org/postgresql/test/jdbc3/GeneratedKeysTest.java
Log Message:
-----------
fix: "Received resultset tuples, but no field structure for them" when bind failure happens on 5th execution of a statement
Current "describe" approach is to set "statement/portal described" flags at "send describe" phase.
It turns out the describe might be skipped (e.g. if bind fails), then query is marked as "described"
however no field information is known.
The fix is to reset "described" flags in "Ready For Query" for the queries in
pendingDescribeStatementQueue / pendingDescribePortalQueue
fixes #811
Compare: https://github.com/pgjdbc/pgjdbc/compare/3e0491ac3833...082d00941ad5
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Sitnikov | 2018-01-02 20:08:38 | [pgjdbc/pgjdbc] 63918e: tests: correct assertion to use proper column |
Previous Message | Michael Paquier | 2017-12-28 07:19:00 | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 |