Обсуждение: [pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) insteadof "Pg...
[pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) insteadof "Pg...
От
Vladimir Sitnikov
Дата:
Branch: refs/heads/master Home: https://github.com/pgjdbc/pgjdbc Commit: 0d31d46adff4e9772db843195e1638531bc703e0 https://github.com/pgjdbc/pgjdbc/commit/0d31d46adff4e9772db843195e1638531bc703e0 Author: Vladimir Sitnikov <sitnikov.vladimir@gmail.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.vladimir@gmail.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