docs: ArcadeDB #7188 framing finding reported on the issue

docs/UPSTREAM.md

@@ -39,7 +39,7 @@ before it is filed.
 | 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` was tracked as [#7188](https://github.com/ArcadeData/arcadedb/issues/7188) and implemented in [#7398](https://github.com/ArcadeData/arcadedb/pull/7398) on 2026-09-10; see that row for the one framing detail still between the driver's default path and ArcadeDB. |
-| 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. | **implemented**: [ArcadeData/arcadedb#7398](https://github.com/ArcadeData/arcadedb/pull/7398) by the maintainer, merged 2026-09-10 (8e9e3d39), ships in 26.10.1 and is in `26.10.1-SNAPSHOT` now: `COPY (<query>) TO STDOUT` in text, csv and binary on both protocol paths. Verified on the snapshot the same day: the stream is correct on the wire (psql and libpq read it, rows match the `Describe` OIDs byte for byte), but the Arrow driver's default path still stops at the first row because ArcadeDB frames the 19-byte binary header as its own `CopyData` message while PostgreSQL sends it inside the first row's message, which the driver's reader relies on (`ReadRecord failed at row 0: expected 2 bytes but found 0`); a one-line change in the executor (do not flush the header on its own) closes it. `adbc.postgresql.use_copy=false` still passes all seven probe steps on that build |
+| 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. | **implemented**: [ArcadeData/arcadedb#7398](https://github.com/ArcadeData/arcadedb/pull/7398) by the maintainer, merged 2026-09-10 (8e9e3d39), ships in 26.10.1 and is in `26.10.1-SNAPSHOT` now: `COPY (<query>) TO STDOUT` in text, csv and binary on both protocol paths. Verified on the snapshot the same day: the stream is correct on the wire (psql and libpq read it, rows match the `Describe` OIDs byte for byte), but the Arrow driver's default path still stops at the first row because ArcadeDB frames the 19-byte binary header as its own `CopyData` message while PostgreSQL sends it inside the first row's message, which the driver's reader relies on (`ReadRecord failed at row 0: expected 2 bytes but found 0`); a one-line change in the executor (do not flush the header on its own) closes it; [reported on the issue](https://github.com/ArcadeData/arcadedb/issues/7188#issuecomment-5647328956) with both servers' chunk dumps on 2026-09-12. `adbc.postgresql.use_copy=false` still passes all seven probe steps on that build |
 | 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 |
 
 ## Documented here, not yet reported