singhpratech · singhpratech · Sep 26, 2026 · Sep 25, 2026
diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md
@@ -27,7 +27,7 @@ before it is filed.
 | 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#301](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/301) | `SQLPrepare` and `SQLExecDirect` discard `SQL_ATTR_ROWS_FETCHED_PTR` and `SQL_ATTR_ROW_STATUS_PTR` set before them, so a block cursor never learns how many rows a fetch returned; set after them they work. Reproduces on 3.0.1 and 3.5.0-rc1. Confirmed on Windows by F.D. Castel 2026-09-06 (cause: the implementation row descriptor was rebuilt on every prepare and cleared its `ROWS_PROCESSED_PTR` / `ARRAY_STATUS_PTR`). | **fix PR [#303](https://github.com/FirebirdSQL/firebird-odbc-driver/pull/303)** (two lines plus a regression test on the report's query), verified on Linux/unixODBC/Firebird 5.0.4 with its CI build on 2026-09-07: correct counters in all three attribute orderings |
 | 2026-08-28 | taos-odbc (TDengine) | [taosdata/taos-connector-odbc#63](https://github.com/taosdata/taos-connector-odbc/issues/63) | Four "not implemented yet" gaps, each with a plain-ODBC program: `SQLBindCol` to `SQL_C_TYPE_TIMESTAMP` (while `SQLGetData` converts), `SQL_TYPE_TIMESTAMP` parameters, `BOOL` parameters from any C type but `SQL_C_SBIGINT`-as-`SQL_TINYINT`, and any `DECIMAL` column failing the whole `SELECT`. taos-odbc from source at 3.3.6.13. | open |
 | 2026-08-28 | Apache Doris | [apache/doris#67301](https://github.com/apache/doris/issues/67301) | Server-side prepared `INSERT` refuses a string parameter sent with MySQL type `BLOB` — what MySQL Connector/ODBC sends for every `SQL_C_WCHAR` parameter — so a Unicode ODBC client cannot insert through prepared statements: `NullPointerException` in the FE on 2.1.0 (stack trace attached), `AnalysisException: Unsupported MySQL type: BLOB` on 4.1.3. Filed with the program and both versions' output. | fix PR open — [apache/doris#67306](https://github.com/apache/doris/pull/67306) by a Doris contributor, "closes #67301"; conflicts resolved at a maintainer's request on 2026-09-11 |
-| 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#582](https://github.com/ClickHouse/clickhouse-odbc/issues/582) | Two parameter-binding defects on 1.5.5.20260810, each with a standalone C program: `SQL_NULL_DATA` is ignored whenever a value buffer is bound and an empty string is sent instead (silently `''` into `String`, the epoch into `DateTime64`, a server parse error for numeric, date, decimal and bool; `SQL_DEFAULT_PARAM` the same; a NULL value pointer works); and parameter arrays — the driver's own `SQLExecute` + `SQLMoreResults`-per-set protocol from #324 — stop after set 1 because `SQLMoreResults` executes it and answers `SQL_NO_DATA`, so a 5-set array lands 2 rows with no diagnostic. | **half fixed** — the `SQL_NULL_DATA` half is fixed by our **fix PR [ClickHouse/clickhouse-odbc#586](https://github.com/ClickHouse/clickhouse-odbc/pull/586)**, opened 2026-09-18 and **merged 2026-09-24** by the maintainer (slabko), merge commit `eb0fdb2654`: a helper that treats a parameter as NULL when the value pointer is null or the indicator is `SQL_NULL_DATA`, used at both sites in `driver/statement.cpp`, with two unit and two integration tests that failed on master. Not in a release: the reproducer was re-run against 1.5.5.20260810 on 2026-09-24 against ClickHouse 26.7.5.10 and still shows all five problems, so the shipped-in line waits for the next tag. The parameter-array half is a separate mechanism (`SQLMoreResults` reports result sets, not parameter sets) and stays open for its own PR, so the issue itself remains open upstream |
+| 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#582](https://github.com/ClickHouse/clickhouse-odbc/issues/582) | Two parameter-binding defects on 1.5.5.20260810, each with a standalone C program: `SQL_NULL_DATA` is ignored whenever a value buffer is bound and an empty string is sent instead (silently `''` into `String`, the epoch into `DateTime64`, a server parse error for numeric, date, decimal and bool; `SQL_DEFAULT_PARAM` the same; a NULL value pointer works); and parameter arrays — the driver's own `SQLExecute` + `SQLMoreResults`-per-set protocol from #324 — stop after set 1 because `SQLMoreResults` executes it and answers `SQL_NO_DATA`, so a 5-set array lands 2 rows with no diagnostic. | **half fixed** — the `SQL_NULL_DATA` half is fixed by our **fix PR [ClickHouse/clickhouse-odbc#586](https://github.com/ClickHouse/clickhouse-odbc/pull/586)**, opened 2026-09-18 and **merged 2026-09-24** by the maintainer (slabko), merge commit `eb0fdb2654`: a helper that treats a parameter as NULL when the value pointer is null or the indicator is `SQL_NULL_DATA`, used at both sites in `driver/statement.cpp`, with two unit and two integration tests that failed on master. Not in a release: the reproducer was re-run against 1.5.5.20260810 on 2026-09-24 against ClickHouse 26.7.5.10 and still shows all five problems, so the shipped-in line waits for the next tag. The parameter-array half is a separate mechanism (`SQLMoreResults` reports result sets, not parameter sets) and is **fix PR [#588](https://github.com/ClickHouse/clickhouse-odbc/pull/588) (ours)**, opened 2026-09-24: `SQLExecute` now sends every set of a statement that returns no result set, and stops at the first set that does, so a `SELECT` keeps handing result sets back one per `SQLMoreResults`. The maintainer's review (2026-09-25) asked for the ODBC error-path contract, added the same day: `SQL_ATTR_PARAMS_PROCESSED_PTR` counts the failing set and `SQL_ATTR_PARAM_STATUS_PTR` reads `{SUCCESS, SUCCESS, ERROR, UNUSED, UNUSED}` on his five-set case, with both cases as tests; verified against ClickHouse 26.7.5.10 on a driver built from the branch, 391 of 392 of the project's own tests passing (the one failure needs `CREATE USER` and fails the same way on 1.5.5). Under review; the issue stays open until it lands |
 | 2026-08-29 | clickhouse-odbc | [ClickHouse/clickhouse-odbc#335 (comment)](https://github.com/ClickHouse/clickhouse-odbc/issues/335#issuecomment-5464127498) | Affected-row count, open since 2021: still 0 (not −1) for every write on 1.5.5 against 26.7.5.10; noted that the server already sends `written_rows` in `X-ClickHouse-Summary` on every HTTP response by default, which the driver could surface. | **fixed 2026-09-15** — [ClickHouse/clickhouse-odbc#585](https://github.com/ClickHouse/clickhouse-odbc/pull/585) (`SQLRowCount` → −1, the ODBC "unknown", where 1.5.5 answered 0) was opened and merged the same day, with a second maintainer's approval, and #335 closed as completed after five years. Verified on the PR's CI build and on the merged master build against ClickHouse 26.7.5.10: −1 after a literal `INSERT` and after a `DELETE`, the full ClickHouse compatibility entry unchanged. Ships in the first release after v1.5.5.20260810. The maintainer's reasoning, 2026-09-15: 0 was wrong and −1 is the honest value; `written_rows` from `X-ClickHouse-Summary` is not usable as an exact count because it is untrusted while `async_insert` is on (ClickHouse/ClickHouse#57768) and, as he then noted and we confirmed, it also counts rows written to materialized views (3 rows through `INSERT … SELECT` with two views reported 7), so −1 is the final answer |
 | 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1470](https://github.com/openlink/virtuoso-opensource/issues/1470) | `virtodbc.so` (Linux, unixODBC) implements `SQL_C_WCHAR` as 4-byte `wchar_t` on both the parameter and the fetch side, not the 2-byte `SQLWCHAR` the driver manager defines: a UTF-16 `hello` stores as `??`, `héllo 🚀` as `0`, wide reads widen each UTF-8 byte — all `SQL_SUCCESS`. The Linux counterpart of #1469. | open |
 | 2026-08-29 | OpenLink Virtuoso | [openlink/virtuoso-opensource#1471](https://github.com/openlink/virtuoso-opensource/issues/1471) | Any `Charset=` value but the exact literal `UTF-8` aborts the process inside `SQLDriverConnect` (`GPF: Dkbox.c:638 Double free`), including every charset Virtuoso itself lists; `Charset=UTF-8` connects but returns wide columns doubly encoded with the original byte length in the indicator. | open — the abort **sent upstream as a fix, [openlink/virtuoso-opensource#1477](https://github.com/openlink/virtuoso-opensource/pull/1477)** (ours, opened 2026-09-18): the cause is a double free, not a compare — `con_charset_name` aliases the parsed option buffer and two owners release it; the fix gives it a box of its own (`libsrc/Wi/CLIsql3.c`, +8/−1), after which every charset connects and an unknown one gets the intended `CL035` warning. The doubly encoded wide columns under `Charset=UTF-8` stay open |
@@ -36,8 +36,8 @@ before it is filed.
 | 2026-08-29 | MySQL Connector/ODBC | [mysql/mysql-connector-odbc#20](https://github.com/mysql/mysql-connector-odbc/issues/20) | `SQLDescribeCol` describes a `DATETIME(6)` column as `COLUMN_SIZE` 19 / `DECIMAL_DIGITS` 0 (values are 26 characters; a buffer sized from the description gets `01004`), and `SQLColumns` reports `COLUMN_SIZE` NULL for `date`/`datetime`; MariaDB Connector/ODBC describes the same column 26/6. Filed on the GitHub mirror (bugs.mysql.com account could not be created). A plain-ODBC probe on 2026-09-04 added the consequence and the root cause for a follow-up: `SQLGetTypeInfo` reports `datetime` as `COLUMN_SIZE` 21 / `MAXIMUM_SCALE` 0, so a client sizing its bind from the type table (pyodbc) stores `13:45:10.123456` as `13:45:10.1` — byte-identical against MySQL 8.4 and SingleStore 9.1, `NO_SSPS=1` or not. | open |
 | 2026-08-29 | MySQL Connector/ODBC | [mysql/mysql-connector-odbc#21](https://github.com/mysql/mysql-connector-odbc/issues/21) | `SHOW VARIABLES`/`SHOW COLLATION` against a MySQL-wire server reporting a zero character-set width (MatrixOne 4.2.0) kill the client with `SIGFPE` in `get_column_size()` (`utility.cc`) during `SQLExecDirect`, before any fetch; the same statement against MySQL 8.4.11 is fine. gdb backtrace included. | open |
 | 2026-08-29 | Apache Ignite ODBC | [apache/ignite#13537](https://github.com/apache/ignite/issues/13537) | Column-wise parameter arrays test the NULL indicator of row 0 for every row: a `SQL_NULL_DATA` below row 0 stores an empty string (`VARCHAR`) or segfaults the client inside `SQLExecute` (`BINARY`, `WriteInt8Array` handed the -1 as a length); a NULL in row 0 nulls the whole batch; row-wise binding refused. `parameter.cpp` cited, fix suggested. | open — **fix PR [#13610](https://github.com/apache/ignite/pull/13610) (ours)**, opened 2026-09-23: the indicator was read from the un-offset buffer in `modules/platforms/cpp/odbc/src/app/parameter.cpp`, before the row offset was applied, so it came from a different row than the value; a negative length also reached `memcpy` in the binary branch. Both offsets are now applied before the indicator is tested, and a negative binary length is written as NULL. Carries a unit test for `app::Parameter`, which had none, covering the current-row indicator for character, binary and integer parameters, a NULL in row 0, a NULL below row 0 and the negative-length case; it needs no server. The reproducer was re-run against a build with the change and all three rows round-trip. The issue itself has had no reply since it was filed. Ignite asks for an ASF JIRA ticket and an `IGNITE-NNNNN` title for code changes: rather than invent a number the pull request says so openly, and contributor access has been requested on `dev@ignite.apache.org` so the ticket can be filed and the title corrected |
-| 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#101](https://github.com/opensearch-project/sql-odbc/issues/101) | Any character value converted to `SQL_C_TYPE_TIMESTAMP`/`SQL_C_TYPE_DATE` comes back as today's date under `SQL_SUCCESS` (`convert.c` fills an unparsed `SIMPLE_TIME` from `localtime`); a `TIMESTAMP` literal takes the same path because the result-set type map lacks `timestamp`. | open |
-| 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#102](https://github.com/opensearch-project/sql-odbc/issues/102) | `SQLError`/`SQLErrorW` return the same connection error on every call and never `SQL_NO_DATA`, so unixODBC's `SQLDriverConnect(W)`, which prefers `SQLError` for a failed connect's diagnostics, spins forever on any failed connect (closed port, `useSSL` mismatch, bad `auth=`); `SQLGetDiagRecW` is correct, and psqlodbc avoids it by not exporting `SQLError`. | open |
+| 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#101](https://github.com/opensearch-project/sql-odbc/issues/101) | Any character value converted to `SQL_C_TYPE_TIMESTAMP`/`SQL_C_TYPE_DATE` comes back as today's date under `SQL_SUCCESS` (`convert.c` fills an unparsed `SIMPLE_TIME` from `localtime`); a `TIMESTAMP` literal takes the same path because the result-set type map lacks `timestamp`. | open — **fix PR [#105](https://github.com/opensearch-project/sql-odbc/pull/105) (ours)**, opened 2026-09-24: the character source types go through `timestamp2stime()` before the output switch and a string it cannot read returns `COPY_INVALID_STRING_CONVERSION`, which had no SQLSTATE and now maps to `22018`. Syntax-checked under GCC with no new diagnostics; not built here (the project's CMake hardcodes a 2019 kernel-headers path and its tests need vcpkg, the AWS SDK and a live cluster), so its CI is the first real run. DCO check green |
+| 2026-08-29 | OpenSearch SQL ODBC | [opensearch-project/sql-odbc#102](https://github.com/opensearch-project/sql-odbc/issues/102) | `SQLError`/`SQLErrorW` return the same connection error on every call and never `SQL_NO_DATA`, so unixODBC's `SQLDriverConnect(W)`, which prefers `SQLError` for a failed connect's diagnostics, spins forever on any failed connect (closed port, `useSSL` mismatch, bad `auth=`); `SQLGetDiagRecW` is correct, and psqlodbc avoids it by not exporting `SQLError`. | open — **fix PR [#104](https://github.com/opensearch-project/sql-odbc/pull/104) (ours)**, opened 2026-09-24: `OPENSEARCHAPI_ConnectError` now clears the connection error after reporting it, as `EN_get_error()` already does for the environment, so the ODBC 2 one-shot contract holds and the driver manager's loop reaches `SQL_NO_DATA_FOUND`; cleared after the last use of the message it points at, and not on the buffer-sizing retry path. Four lines. Same build caveat as #105; DCO check green |
 | 2026-08-29 | QuestDB | [questdb/questdb#7566](https://github.com/questdb/questdb/issues/7566) | A `BINARY` column in a simple-query result is sent with format code 1 (raw bytes) where PostgreSQL always sends text, so libpq/psycopg and psqlodbc truncate the value at its first `0x00`; the extended protocol returns it whole. Side by side with PostgreSQL 16 via `PQfformat`. | fix PR open — [questdb/questdb#7569](https://github.com/questdb/questdb/pull/7569) |
 | 2026-08-29 | QuestDB | [questdb/questdb#7567](https://github.com/questdb/questdb/issues/7567) | `DEALLOCATE ALL` fails with `Cannot invoke "io.questdb.cutlass.pgwire.PGPipelineEntry.close()" because "pe" is null` — even on a fresh autocommit connection with nothing prepared; a named `DEALLOCATE` works. | fix PR open — [questdb/questdb#7568](https://github.com/questdb/questdb/pull/7568) |
 | 2026-08-29 | CrateDB | [crate/crate#20085](https://github.com/crate/crate/issues/20085) | A multi-statement simple query returns each `CommandComplete` tagged with the leading text of the whole string (`BEGIN;INSERT 0`, `BEGIN;INSERT 1`) instead of per-statement tags (`BEGIN`, `INSERT 0 1`), so tag-parsing clients such as psqlodbc get no row count inside a transaction. | **fixed** — [crate/crate#20088](https://github.com/crate/crate/pull/20088) merged 2026-08-31, ships in 6.4.4 |