[pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) insteadof "Pg... - Mailing list pgsql-jdbc

From Vladimir Sitnikov
Subject [pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) insteadof "Pg...
Date
Msg-id 5a4bd6554474f_7aa82b0b24a15c0c76385@hookshot-fe-cace476.cp1-iad.github.net.mail
Whole thread Raw
List 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.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

pgsql-jdbc by date:

Previous
From: Jorge Solorzano
Date:
Subject: [pgjdbc/pgjdbc] b62993: chore: collect coverage for Java 7 (#1030)
Next
From: Vladimir Sitnikov
Date:
Subject: [pgjdbc/pgjdbc] 63918e: tests: correct assertion to use proper column