singhpratech · singhpratech · Sep 23, 2026 · Sep 23, 2026
diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md
@@ -44,7 +44,7 @@ before it is filed.
 | 2026-08-29 | psqlodbc | [postgresql-interfaces/psqlodbc#207](https://github.com/postgresql-interfaces/psqlodbc/issues/207) | `SQLGetData`/`SQLBindCol` narrow an out-of-range `int8` to `SQL_C_SLONG` (and to `SQL_C_SSHORT`) silently — `9223372036854775807::bigint` reads as `-1` under `SQL_SUCCESS` where ODBC specifies `22003`; `pg_atol`/`pg_atoi` in `convert.c` store the low bits with no range check. Stock PostgreSQL 16. | **fixed** — [postgresql-interfaces/psqlodbc#210](https://github.com/postgresql-interfaces/psqlodbc/pull/210) by Dave Cramer, merged 2026-09-04 (`SQLGetData`/`SQLBindCol` now return `SQL_ERROR` with `22003` for an out-of-range integer conversion instead of the wrapped low bits); verified on the merge commit `4a5a0e7` on 2026-09-04, `SQLGetData` and `SQLBindCol` paths, results on the issue. Follow-up [postgresql-interfaces/psqlodbc#211](https://github.com/postgresql-interfaces/psqlodbc/pull/211), merged 2026-09-08 from the aside in that verification, drops the C-type size from the indicator on the error rows too; verified on `d747b18` on 2026-09-10. **Fixed in psqlodbc 18.00.0003** (`REL-18_00_0003`, released 2026-09-10): the release tag built from source and re-run with the program on 2026-09-10, same results on both paths |
 | 2026-08-29 | psqlodbc | [postgresql-interfaces/psqlodbc#208](https://github.com/postgresql-interfaces/psqlodbc/issues/208) | With `Protocol=7.4-0`, `SQLFreeHandle` of a prepared statement inside a transaction still sends `SAVEPOINT _per_query_svp_;DEALLOCATE …;RELEASE`; on a server without `SAVEPOINT` (QuestDB, Materialize) the error is swallowed, the server rolls the transaction back and `SQLEndTran(SQL_COMMIT)` returns `SQL_SUCCESS` for rows that are gone. Wire capture included. | **fixed** — [postgresql-interfaces/psqlodbc#209](https://github.com/postgresql-interfaces/psqlodbc/pull/209) by Dave Cramer, merged 2026-09-02 (rollback level 0 no longer savepoint-wraps the internal `DEALLOCATE`; the tested branch commit is the merged one); QuestDB confirmed; Materialize's own half, [MaterializeInc/materialize#38606](https://github.com/MaterializeInc/materialize/pull/38606), merged 2026-09-14 and verified with this program the same day (see the Materialize row). **Fixed in psqlodbc 18.00.0003** (`REL-18_00_0003`, released 2026-09-10): release tag built from source and re-run with the program on 2026-09-10, QuestDB keeps both rows when the statement is freed before the commit (stock 16.00 loses both), PostgreSQL 16.15 unchanged |
 | 2026-09-01 | Materialize | [MaterializeInc/materialize#38605](https://github.com/MaterializeInc/materialize/discussions/38605) (bug-report discussion; their tracker) | `DEALLOCATE "Name"` does not unquote the identifier, so a statement prepared at the protocol level (`Parse`) with a mixed-case name — psqlodbc's `_PLAN0x…` — cannot be released: `26000 prepared statement "\"_PLAN0x7\"" does not exist`, and inside a transaction the failure aborts it; PostgreSQL 16 releases the same statement. Filed with a psycopg side-by-side against PostgreSQL 16. The server half of the psqlodbc#208 row-loss pair. | **fixed on main** — [MaterializeInc/materialize#38606](https://github.com/MaterializeInc/materialize/pull/38606) by antiguru (Materialize), merged 2026-09-14 (9adca52d); unquotes prepared-statement, portal and cursor names before lookup. Verified the same day on the `v26.43.0-dev.0--main.g9adca52d` image with the #208 program and psqlodbc 18.00.0004, `Protocol=7.4-0`: a statement freed before the commit keeps both rows (2/2), where the Aug 19 `latest` image loses both with the same driver and the stock 16.00 driver loses both on either server; [results posted on the PR](https://github.com/MaterializeInc/materialize/pull/38606#issuecomment-5670188317). Not in a Materialize release yet |
-| 2026-09-04 | SingleStore Connector/ODBC | [memsql/singlestore-odbc-connector#45](https://github.com/memsql/singlestore-odbc-connector/issues/45) | `SQLGetTypeInfo` fails `42S22 Unknown column 'json' in 'field list' (1054)` whenever `sql_mode` contains `ANSI_QUOTES`: the type-info result set is built from a template with double-quoted string literals (`ma_info.c`), which that mode turns into identifiers. `SQLTables`/`SQLColumns`/queries unaffected; MySQL Connector/ODBC fine on the same server. | open — **fix PR [#48](https://github.com/memsql/singlestore-odbc-connector/pull/48) (ours)**, opened 2026-09-17: single-quoted literals in the template, with a test under `ANSI_QUOTES`; verified against SingleStore 9.1.1 |
+| 2026-09-04 | SingleStore Connector/ODBC | [memsql/singlestore-odbc-connector#45](https://github.com/memsql/singlestore-odbc-connector/issues/45) | `SQLGetTypeInfo` fails `42S22 Unknown column 'json' in 'field list' (1054)` whenever `sql_mode` contains `ANSI_QUOTES`: the type-info result set is built from a template with double-quoted string literals (`ma_info.c`), which that mode turns into identifiers. `SQLTables`/`SQLColumns`/queries unaffected; MySQL Connector/ODBC fine on the same server. | **fixed** — **fix PR [#48](https://github.com/memsql/singlestore-odbc-connector/pull/48) (ours)**, opened 2026-09-17, approved and merged 2026-09-23 by the maintainer (Pavlo Mishchenko), merge commit `182ae5b515`, closing the issue the same minute: single-quoted literals in the template, with a test under `ANSI_QUOTES`. Verified against SingleStore 9.1.1, and the driver was rebuilt from the merged branch here on 2026-09-23 with the whole `info` suite green in both the client-side and the server-side prepared-statement modes. Review asked for the test to run on its own connection, following the project's `odbc143`, and to restore `sql_mode` before disconnecting; both landed in the second commit. Not yet in a release: `master` is still 1.2.2, so the shipped-in line waits for the next tag |
 | 2026-09-05 | ArcadeDB | [ArcadeData/arcadedb#7178](https://github.com/ArcadeData/arcadedb/issues/7178) (opened by the maintainer from the [discussion follow-up](https://github.com/ArcadeData/arcadedb/discussions/6888#discussioncomment-18309009)) | The Arrow native PostgreSQL ADBC driver cannot connect to ArcadeDB's PostgreSQL-protocol plugin: its type-resolver bootstrap `SELECT oid, typname, typreceive, typbasetype, typrelid, typarray FROM pg_catalog.pg_type WHERE …` is answered with zero columns (`Expected 5 or 6 columns from type resolver pg_type query but got 0`), because the emulated `pg_type` knows neither `typreceive` nor `typsend` and its WHERE parser accepts only a single equality. Found by the 2026-09-05 native-driver probe; the maintainer's own diagnosis is in the issue. | **fixed on main**: [ArcadeData/arcadedb#7179](https://github.com/ArcadeData/arcadedb/pull/7179), opened by the maintainer the same day and merged 2026-09-06 (558e6042); ships in ArcadeDB 26.10.1 (October 2026, per the maintainer) and is in `26.10.1-SNAPSHOT` now. Verified on the PR's CI build with the fixture types present: the native driver connects and `GetObjects` lists the types; with the driver's defaults it then stops at the first result set because ArcadeDB has no `COPY (…) TO STDOUT (FORMAT binary)` (the CockroachDB, CrateDB and YDB stop); with `adbc.postgresql.use_copy=false` reads work end to end and only `GetTableSchema` (its `$1::regclass::oid` lookup) returns an empty schema. Follow-up issue [#7180](https://github.com/ArcadeData/arcadedb/issues/7180) carried the driver's exact statements; its `GetTableSchema` item (the `::regclass` cast) is **fixed in [#7187](https://github.com/ArcadeData/arcadedb/pull/7187)**, merged 2026-09-06 (ec871770), verified on its CI build: five and eight fields with the right Arrow types. Binary `COPY` was tracked as [#7188](https://github.com/ArcadeData/arcadedb/issues/7188), implemented in [#7398](https://github.com/ArcadeData/arcadedb/pull/7398) on 2026-09-10 and framed like PostgreSQL's in [#7607](https://github.com/ArcadeData/arcadedb/pull/7607) on 2026-09-15; with all three, the native driver passes the whole probe with its defaults on `26.10.1-SNAPSHOT`. |
 | 2026-09-06 | ArcadeDB | [ArcadeData/arcadedb#7188](https://github.com/ArcadeData/arcadedb/issues/7188) (opened by the maintainer from the probe follow-up) | `COPY (<query>) TO STDOUT`, text and binary, is not supported by the PostgreSQL-protocol plugin; the Arrow native PostgreSQL ADBC driver reads every result through binary `COPY` by default, so with defaults it stops at the first result set. The driver's `adbc.postgresql.use_copy=false` statement option reads through ordinary binary-format results and works end to end on ArcadeDB, which the issue records. | **fixed on main**: [ArcadeData/arcadedb#7398](https://github.com/ArcadeData/arcadedb/pull/7398) (merged 2026-09-10) implemented `COPY (<query>) TO STDOUT` in text, csv and binary on both protocol paths; the one framing detail left between it and the Arrow driver's default path (the binary header sent as its own `CopyData` message, [reported](https://github.com/ArcadeData/arcadedb/issues/7188#issuecomment-5647328956) with both servers' chunk dumps on 2026-09-12) was fixed by the maintainer in [ArcadeData/arcadedb#7607](https://github.com/ArcadeData/arcadedb/pull/7607), merged 2026-09-15 (3bdb3451b). Verified the same morning on `26.10.1-SNAPSHOT` build 99f4cb48: the Arrow PostgreSQL ADBC driver 1.12.0 with its defaults passes all seven probe steps and decodes real rows (int64, string, double, date32, bool) through binary COPY, no `use_copy=false` needed. The maintainer closed the issue on 2026-09-15; re-verified the same day past the probe — an empty result set (header and trailer with no rows, the case the fix names), one row, 10,000 rows in one `COPY`, a NULL in every column, non-BMP text, `GetTableSchema` and `GetObjects` — all correct with the driver's defaults. Ships in ArcadeDB 26.10.1 |
 | 2026-09-04 | SingleStore Connector/ODBC | [memsql/singlestore-odbc-connector#46](https://github.com/memsql/singlestore-odbc-connector/issues/46) | `SQLColumns` with a NULL `CatalogName` segfaults the client on a connection opened without `Database=`: `TABLE_CAT` falls back to the client library's current-database field, which stays NULL after `USE`, and `strdup(NULL)` is called (`ma_statement.c`). Zero matching rows, an explicit catalog, or `Database=` in the connection string avoid it. | open — **fix PR [#47](https://github.com/memsql/singlestore-odbc-connector/pull/47) (ours)**, opened 2026-09-17: `TABLE_CAT` NULL instead of `strdup(NULL)` in `SQLColumns` and `SQLPrimaryKeys`, with a test; verified against SingleStore 9.1.1 |

diff --git a/tests/compat/README.md b/tests/compat/README.md
@@ -6507,7 +6507,7 @@ Each has one thing the other does not:
 | `PLUGIN_DIR=` | required (`mysql_native_password`) | not needed |
 | `LD_PRELOAD=libstdc++.so.6` under pyarrow | required | not needed |
 | `DATETIME(6)` described as | size 19, scale 0 | size 26, scale 6 |
-| `SQLGetTypeInfo` under `ANSI_QUOTES` | works | **fails, 42S22** |
+| `SQLGetTypeInfo` under `ANSI_QUOTES` | works | **fails, 42S22** on 1.2.2; fixed upstream in [#48](https://github.com/memsql/singlestore-odbc-connector/pull/48) (merged 2026-09-23, unreleased) |
 | already provisioned | yes, `$MYSQL_ODBC_DRIVER` | separate download |
 
 **The entry uses MySQL Connector/ODBC**, because it is what the eleven other MySQL-wire
@@ -6516,11 +6516,16 @@ costs one `export SINGLESTORE_ODBC_DRIVER=$MYSQL_ODBC_DRIVER` line and no new dr
 because its `SQLGetTypeInfo` survives the `ANSI_QUOTES` the entry sets, so generated
 ingest DDL is spelled in the server's own type names.
 
-### The SingleStore driver's `SQLGetTypeInfo` breaks under `ANSI_QUOTES` (42S22)
+### The SingleStore driver's `SQLGetTypeInfo` breaks under `ANSI_QUOTES` (42S22), fixed upstream
 
 Worth recording precisely, because it is a real driver bug and the failure is silent
-through adbcBridge. Against SingleStore ODBC 1.2.2, `SQLGetTypeInfo` succeeds on a fresh
-connection and fails on the same connection once `ANSI_QUOTES` is in `sql_mode`:
+through adbcBridge. Reported as
+[memsql/singlestore-odbc-connector#45](https://github.com/memsql/singlestore-odbc-connector/issues/45)
+and fixed by our
+[PR #48](https://github.com/memsql/singlestore-odbc-connector/pull/48), merged 2026-09-23; the
+behaviour below is what SingleStore ODBC 1.2.2, the current release, still does. On 1.2.2
+`SQLGetTypeInfo` succeeds on a fresh connection and fails on the same connection once
+`ANSI_QUOTES` is in `sql_mode`:
 
 ```
 SQLGetTypeInfo(SQL_ALL_TYPES) -> 42S22  [ss-1.2.2][9.1.1]Unknown column 'json'