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

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема [pgjdbc/pgjdbc] 0d31d4: fix: throw TOO_MANY_RESULTS (0100E) insteadof "Pg...
Дата
Msg-id 5a4bd6554474f_7aa82b0b24a15c0c76385@hookshot-fe-cace476.cp1-iad.github.net.mail
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Jorge Solorzano
Дата:
Сообщение: [pgjdbc/pgjdbc] b62993: chore: collect coverage for Java 7 (#1030)
Следующее
От: Vladimir Sitnikov
Дата:
Сообщение: [pgjdbc/pgjdbc] 63918e: tests: correct assertion to use proper column