singhpratech · singhpratech · Sep 10, 2026 · Sep 10, 2026
diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md
@@ -34,8 +34,8 @@ before it is filed.
 | 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 |
-| 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. Not in a tagged release yet (latest `REL-18_00_0002`, 2026-07-02) |
-| 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 waits on its own fix |
+| 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 waits on its own fix. **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. | **fix in review** — [MaterializeInc/materialize#38606](https://github.com/MaterializeInc/materialize/pull/38606) by antiguru (Materialize), opened 2026-09-01; unquotes prepared-statement, portal and cursor names before lookup |
 | 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 |
 | 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` is tracked as [#7188](https://github.com/ArcadeData/arcadedb/issues/7188). |