From 39d790406353f5f21abafb5432fbed475ab444dc Mon Sep 17 00:00:00 2001 From: singhpratech <42719720+singhpratech@users.noreply.github.com> Date: Sat, 12 Sep 2026 12:50:48 -0400 Subject: [PATCH] docs: ArcadeDB #7188 implemented in #7398 (26.10.1), verified on the snapshot; Doris #67306 conflicts resolved ArcadeDB's maintainer implemented COPY ... TO STDOUT (text, csv, binary, both protocol paths) in #7398, merged 2026-09-10 and in 26.10.1-SNAPSHOT. Verified the same day: the stream is correct on the wire and rows match the Describe OIDs, but the Arrow driver's default path still stops at row 0 because the binary header is framed as its own CopyData message where PostgreSQL bundles it with the first row; use_copy=false still passes 7/7. Doris #67306: conflicts resolved at a maintainer's request on 2026-09-11. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_012QpuUDF9x53Bi3sGo9zXDT --- docs/COMPATIBILITY.md | 2 +- docs/UPSTREAM.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/COMPATIBILITY.md b/docs/COMPATIBILITY.md index 26ca814..defd4d4 100644 --- a/docs/COMPATIBILITY.md +++ b/docs/COMPATIBILITY.md @@ -110,7 +110,7 @@ table with neither gets one partition. The numbers are in | InfluxDB 3 Core (InfluxDB IOx 2.0, Arrow Flight SQL) | Flight SQL ODBC 0.9.7 (Dremio, open source) | PASS (read) | a second Flight SQL server behind the same driver, and it needed no new driver quirk (the `SQLColumns` one is shared with sqlflite — here it crashes only for tables whose Flight SQL schema carries no per-field metadata, InfluxDB's `system` and `information_schema` tables, while the entry's own `iox` tables fetch cleanly); the entry is read-only twice over (InfluxDB 3's SQL is query-only — DDL answers `DDL not supported: `, DML `DML not supported: `, and tables come into existence when line protocol is written to them over the HTTP API — and the driver has no `SQLBindParameter`); server side: a table is tags, fields and a nanosecond `time` column that is always spelled `time`, with no `DATE`, `DECIMAL` or binary type, so the entry reads `time` as `ts` and casts the date back in its own `SELECT`; fetch 1.03M rows/s | | Dremio 26.0.5 (OSS, Arrow Flight SQL) | Flight SQL ODBC 0.9.7 (Dremio, open source) | PASS (read) | the engine that publishes this driver, and it needed no new driver quirk — `no_sql_columns` is keyed on the driver name, so Dremio takes the path shared with sqlflite and InfluxDB, though against Dremio 26 `SQLColumns` does not in fact crash (it describes its 18 result columns and fetches every row), so here the quirk costs a describe rather than avoiding a segfault; read-only because of the driver alone -- Dremio writes fine (`$scratch`, the writable source a stock dremio-oss ships, takes CTAS, and a table created there with a column list is Iceberg and takes `INSERT`), but `SQLBindParameter` is `HYC00 Unsupported function` even after a `SQLPrepare` that succeeds, and `SQLNumParams` reports 0, so no parameter can reach the server and `setup` builds both tables with literal `CREATE TABLE IF NOT EXISTS ... AS SELECT`; unlike sqlflite the driver reports a `DECIMAL`'s declared scale — described as (19, *s*), precision still always 19 — so decimals arrive exact in a wider decimal128 rather than as text; a string literal holding any character outside ISO-8859-1 (a BMP `漢` as much as an emoji) needs the `_UTF8'…'` prefix or Dremio's parser encodes it as ISO-8859-1 and fails planning; server side, the first admin user has to be created over the REST API before any login works, and the query context comes from a `schema` connection property the driver forwards as a gRPC header; fetch 1.1M rows/s | | Microsoft Access `.mdb`/`.accdb` | MDB Tools 1.0 (`odbc-mdbtools`) | PASS (read) | the driver executes no DDL/DML and has no `SQLBindParameter`; 32-bit `SQLLEN`, as Db2 | -| ArcadeDB 26.9 (PostgreSQL wire) | psqlodbc 16 (PG wire) | PASS (read) | multi-model engine behind the PG wire: no `CREATE TABLE` at all (a table is a document type plus one `CREATE PROPERTY` per column), so `adbc_ingest`'s generated DDL has nowhere to go and the entry runs the read side — queries, parameters and the catalog all work; driver quirks handled: psqlodbc's `SQLColumns` and `SQLTables(SQL_ALL_TABLE_TYPES)` are queries its parser will not run -- `SQLColumns` answers `SQL_SUCCESS` with zero rows, `SQLTables(SQL_ALL_TABLE_TYPES)` answers `SQL_ERROR` -- so `GetObjects` describes a zero-row SELECT and `GetTableTypes` falls back to the types the server's own tables have; `BoolsAsChar=0`, ISO-8601 `T` timestamp literals, `@rid`/`@type`/`@cat` in every `SELECT *`; also traverses a small graph (vertices, edges, `expand(out())`); fetch 332k rows/s. Native-driver status, for comparison: the Apache Arrow PostgreSQL ADBC driver (1.12.0) could not connect at all until ArcadeDB fixed its `pg_type` bootstrap ([#7178](https://github.com/ArcadeData/arcadedb/issues/7178), opened and merged by the maintainer within a day of the [probe note](https://adbcbridge.org/notes/native-adbc-drivers-on-wire-compatible-databases/), 2026-09-06; ships in 26.10.1, in `26.10.1-SNAPSHOT` now); on the merged build it connects and lists types, stops at `COPY … TO STDOUT (FORMAT binary)` with its defaults, and with `adbc.postgresql.use_copy=false` reads the fixture end to end; `GetTableSchema`'s `::regclass` lookup, the last catalog gap, is fixed in [#7187](https://github.com/ArcadeData/arcadedb/pull/7187) (merged 2026-09-06, also in 26.10.1); binary `COPY` itself is tracked as [#7188](https://github.com/ArcadeData/arcadedb/issues/7188) | +| ArcadeDB 26.9 (PostgreSQL wire) | psqlodbc 16 (PG wire) | PASS (read) | multi-model engine behind the PG wire: no `CREATE TABLE` at all (a table is a document type plus one `CREATE PROPERTY` per column), so `adbc_ingest`'s generated DDL has nowhere to go and the entry runs the read side — queries, parameters and the catalog all work; driver quirks handled: psqlodbc's `SQLColumns` and `SQLTables(SQL_ALL_TABLE_TYPES)` are queries its parser will not run -- `SQLColumns` answers `SQL_SUCCESS` with zero rows, `SQLTables(SQL_ALL_TABLE_TYPES)` answers `SQL_ERROR` -- so `GetObjects` describes a zero-row SELECT and `GetTableTypes` falls back to the types the server's own tables have; `BoolsAsChar=0`, ISO-8601 `T` timestamp literals, `@rid`/`@type`/`@cat` in every `SELECT *`; also traverses a small graph (vertices, edges, `expand(out())`); fetch 332k rows/s. Native-driver status, for comparison: the Apache Arrow PostgreSQL ADBC driver (1.12.0) could not connect at all until ArcadeDB fixed its `pg_type` bootstrap ([#7178](https://github.com/ArcadeData/arcadedb/issues/7178), opened and merged by the maintainer within a day of the [probe note](https://adbcbridge.org/notes/native-adbc-drivers-on-wire-compatible-databases/), 2026-09-06; ships in 26.10.1, in `26.10.1-SNAPSHOT` now); on the merged build it connects and lists types, stops at `COPY … TO STDOUT (FORMAT binary)` with its defaults, and with `adbc.postgresql.use_copy=false` reads the fixture end to end; `GetTableSchema`'s `::regclass` lookup, the last catalog gap, is fixed in [#7187](https://github.com/ArcadeData/arcadedb/pull/7187) (merged 2026-09-06, also in 26.10.1); binary `COPY` itself, [#7188](https://github.com/ArcadeData/arcadedb/issues/7188), was implemented in [#7398](https://github.com/ArcadeData/arcadedb/pull/7398) on 2026-09-10 (also 26.10.1); on the snapshot the stream is right on the wire but the driver's default path still stops on one framing detail (the binary header sent as its own `CopyData` message), so `use_copy=false` remains the working route for the native driver until that lands | | Materialize 26.38 | psqlodbc 16 (PG wire) | PASS | streaming warehouse; PostgreSQL SQL layer, so no driver quirks -- but no `SAVEPOINT`, so the entry sets psqlodbc's `Protocol=7.4-0` to stop the driver wrapping the second batch of a large ingest in one; its single 39-digit `NUMERIC` is wider than an Arrow decimal128, so decimals read back as exact strings; also ingests into and reads back an incrementally maintained `MATERIALIZED VIEW`; ingest 23.6k rows/s (23.7k with array binding), fetch 322k rows/s | | Apache Ignite 2.17 | Ignite ODBC (built from the sources in the image) | PASS | in-memory key-value grid with a SQL engine: no prebuilt Linux driver exists, so `platforms/cpp` is built root-free (`-DWITH_ODBC=ON -DWITH_CORE=OFF`, no JVM); driver quirks handled: no wide SQL type at all (`SQL_WVARCHAR` refused outright by `SQLBindParameter`, `SQL_C_WCHAR` sized in `wchar_t`) so the UTF-8 narrow path, as for Firebird, and column-wise parameter arrays that test the NULL indicator of row 0 for every row — a NULL below the first row is dropped rather than sent: a character column stores an empty string, and a `BINARY` column segfaults the client inside `SQLExecute` (`WriteInt8Array` is handed the -1 indicator as its length), so arrays are off (row-wise binding is refused outright). `SQL_DRIVER_VER` and `SQL_DBMS_VER` are both the hardcoded `02.04.0000`, neither the server's 2.17.0 nor the negotiated protocol 2.13.0. Server side: every table is a cache and must declare a `PRIMARY KEY`, which generated ingest DDL cannot, so `mode="create"` is impossible (`ingest_create=False`) and the entry ingests by appending into a keyed table; identifiers fold to upper case and the driver reports no quote character. Fetch 930k rows/s; append into a keyed table ~95k rows/s | | Google Cloud Spanner (emulator + PGAdapter 0.55) | psqlodbc 16 (PG wire) | PASS | two driver quirks, both keyed on a PGAdapter-only setting because `version()` just says PostgreSQL 14.1: psqlodbc inlines a parameter array's timestamps as `'...'::timestamp`, a type Spanner does not have, so a batch binding a timestamp goes row-at-a-time (`no_timestamp_param_arrays`); and every Spanner table needs a PRIMARY KEY, so generated ingest DDL adds a surrogate `GENERATED BY DEFAULT AS IDENTITY` column (`ingest_key_column`). Server side: no 32-bit integer, no `TIMESTAMP WITHOUT TIME ZONE` (so `ts` reads back zone-aware), no modifier on `NUMERIC`, no DDL inside a transaction; also ingests into and reads back an `INTERLEAVE IN PARENT` child table. A third quirk on the same key is Spanner's ceiling of **950 parameters per statement** (`max_statement_params`): PGAdapter prepares a multi-row INSERT that carries more without complaint and then closes the connection at `SQLExecute` (`08S01`), leaving the batching's halving search no connection to halve on -- measured exactly, 948 parameters go through and 952 drop the connection -- so it is declared rather than probed, and ingest runs at 237 four-column rows per INSERT. ingest 7.3k rows/s (7.4k with array binding), fetch 95.8k rows/s at `--rows 300 --fetch-rows 2000`, which is the size this entry is benchmarked at | diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md index d984004..2b5bdd6 100644 --- a/docs/UPSTREAM.md +++ b/docs/UPSTREAM.md @@ -19,7 +19,7 @@ before it is filed. | 2026-08-28 | Firebird ODBC (OdbcFb) | [FirebirdSQL/firebird-odbc-driver#300](https://github.com/FirebirdSQL/firebird-odbc-driver/issues/300) | Once a NULL has been bound to a `SQL_BIGINT` parameter with a character C type (`SQL_C_DEFAULT` or `SQL_C_CHAR`), every later `SQL_C_SBIGINT` rebind of that parameter writes NULL; `INTEGER` with the same pattern is fine. Reproduces on 3.0.1 and 3.5.0-rc1. | open — **Confirmed and widened 2026-09-06** by a Firebird community contributor on Windows (Firebird ODBC 3.0.1.21, Firebird 3.0.13): `SQL_NUMERIC` and `SQL_DECIMAL` parameters lose the same way, hit through DuckDB's odbc-scanner on a 485k-row `NUMERIC(9,3)` column; root cause traced in the driver source (`SQL_C_DEFAULT` resolves to `SQL_C_CHAR` for BIGINT/NUMERIC/DECIMAL, `setTypeText()` overwrites the prepared XSQLVAR, and the rebind re-describes the parameter from the mutated var), with a fix proposed (describe INPUT parameters from the prepare-time snapshot) and a regression test shape. adbcBridge is unaffected: NULLs bind `SQL_C_SBIGINT` for BIGINT and decimals travel as `SQL_C_CHAR` text, the C type the values use. **Fix PR [#302](https://github.com/FirebirdSQL/firebird-odbc-driver/pull/302)** by F.D. Castel (2026-09-06): INPUT parameters are described from the prepare-time snapshot; verified on Linux/unixODBC/Firebird 5.0.4 with its CI build on 2026-09-07 — both C programs from the report correct in every shape, the 24-cell matrix 0 lost against 6 on the release build. | | 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" | +| 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. | open | | 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. | open | | 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 | @@ -38,8 +38,8 @@ before it is filed. | 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). | -| 2026-09-06 | ArcadeDB | [ArcadeData/arcadedb#7188](https://github.com/ArcadeData/arcadedb/issues/7188) (opened by the maintainer from the probe follow-up) | `COPY () 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. | open, enhancement (scoped by the maintainer as protocol work) | +| 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 () 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 () 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-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