singhpratech · singhpratech · Sep 21, 2026 · Sep 21, 2026
diff --git a/docs/UPSTREAM.md b/docs/UPSTREAM.md
@@ -48,6 +48,7 @@ before it is filed.
 | 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 |
+| 2026-09-21 | ArcadeDB | [ArcadeData/arcadedb#8090](https://github.com/ArcadeData/arcadedb/issues/8090) | A `DATETIME_MICROS` (also `DATETIME_NANOS`, `DATETIME`) value written as a string with a space separator **and** a fractional second — `'2024-02-29 13:45:10.123456'`, exactly the form psqlodbc renders a bound timestamp in — is stored as `NULL` while the `INSERT` reports success. Either half alone is fine: the `T` separator round-trips, and the space form without a fraction round-trips. Carried into the project's own tracker by a maintainer after we documented it in the compatibility notes, with the root cause named: a blanket catch in `Type.convert()` logs at `FINE` and returns `null`. Every PostgreSQL-wire client that binds a timestamp against a sub-second property is affected, not only this driver | **open**, filed 2026-09-21 by the project (Luca Garulli) and labelled `severity:critical`, crediting the report; a reproducer and the root cause are in the issue |
 
 ## Documented here, not yet reported
 
@@ -73,7 +74,6 @@ time allows, and a reproduction contributed by anyone is welcome.
 | DuckDB ODBC 1.5.5 (Linux) | (`SQLGetInfo(SQL_DBMS_VER)` segfault and the parameter-array defect: both sent upstream as fixes and both merged on 2026-09-17, see duckdb/duckdb-odbc#523 and #524 above.) A fetch writes the full 2048-row vector into bound buffers whatever the rowset size. adbcBridge binds row by row and fetches 2048-row rowsets there. | `COMPATIBILITY.md`, `tests/compat/README.md` |
 | RisingWave 3.0 | A server-side statement name is not released when the client closes the statement, so psqlodbc's `_PLAN0x<handle>` names collide on the second prepare of an allocate/prepare/execute/free loop (`XX000 Duplicated statement name`). adbcBridge sets `UseServerSidePrepare=0` there. | `COMPATIBILITY.md` |
 | OceanBase CE 4.4.2 | A server-side prepared execute in which a parameter arrives as `MYSQL_TYPE_NULL` (what MySQL Connector/ODBC sends for a NULL before a value has fixed the type) is refused with `Object type error` (4001); MySQL accepts the same sequence. | `COMPATIBILITY.md` |
-| ArcadeDB 26.9 (PostgreSQL wire) | A `DATETIME_MICROS` literal written with a space separator and a fraction (`'2024-02-29 13:45:10.123456'`, the form psqlodbc renders a bound timestamp in) is stored as NULL under `SQL_SUCCESS`; a NULL `BOOLEAN` arrives over the wire as `false` with a non-NULL indicator. | `tests/compat/README.md` |
 | `alexbrainman/odbc` (Go, Windows) | Access violation inside `api.SQLGetDiagRec` on the first driver diagnostic, on every server but SQLite. | `bench/LANGUAGE_BENCHMARKS-windows.md` |
 | psqlodbc 18.x | Sends `SHOW DateStyle` at connect, which YDB's PostgreSQL layer rejects; 16.x does not. (Arguably YDB's to implement.) | `COMPATIBILITY.md`, macOS and Windows columns |
 | Firebird ODBC 3.0.1 / 3.5.0-rc1 | No macOS build; Firebird 5's sample security database ships with no SYSDBA and bootstrapping one needs an administrator. | `COMPATIBILITY.md` |

diff --git a/tests/compat/README.md b/tests/compat/README.md
@@ -3505,12 +3505,20 @@ that path, since every other driver answers the enumeration.
 * **`BoolsAsChar=0`** in the connection string. Without it psqlodbc reports every
   `BOOLEAN` as a `VARCHAR(5)` holding `"1"`/`"0"` instead of `SQL_BIT`. Same setting, same
   reason, as the `questdb` entry.
-* **`not_null=("bo",)`.** With `BoolsAsChar=0` a boolean property has no NULL state on
-  the wire: row 2's `bo` goes in as `NULL` and reads back `False`.
+* **`not_null=("bo",)`.** With `BoolsAsChar=0` a boolean property had no NULL state on
+  the wire: row 2's `bo` went in as `NULL` and read back `False`. Observed on 26.8.1
+  (2026-08-28). Fixed upstream in
+  [ArcadeData/arcadedb#6674](https://github.com/ArcadeData/arcadedb/issues/6674), which a
+  project contributor filed and closed on 2026-08-24, and the fix shipped in 26.9.1: a
+  retest on the 26.9.1 image on 2026-09-21 reads a NULL property and an absent property
+  both back as SQL NULL, on the text and the binary result format. The flag stays for now
+  because the matrix still records 26.9 for this entry.
 * **`decimal_type="decimal128(28, 3)"`.** ArcadeDB reports no declared precision for a
   `DECIMAL` property, so psqlodbc falls back to its own maximum (28) with the scale of the
   values in the result set — as it does for RisingWave's unqualified `NUMERIC`.
-* **Timestamp literals need the ISO-8601 `T`.** `'2024-02-29 13:45:10.123456'` into a
+* **Timestamp literals need the ISO-8601 `T`.** Reported upstream on 2026-09-21 as
+  [ArcadeData/arcadedb#8090](https://github.com/ArcadeData/arcadedb/issues/8090),
+  `severity:critical`. `'2024-02-29 13:45:10.123456'` into a
   `DATETIME_MICROS` property is stored as `NULL`, silently;
   `'2024-02-29T13:45:10.123456'` round-trips to the microsecond. (A bound
   `SQL_TYPE_TIMESTAMP` parameter goes as the space form, so it hits the same silent NULL —