[pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) instead of "Pg...

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

Browse pgsql-jdbc by date

  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