ArcadeDB 26.11.1: four fixes confirmed in a release, and the connect string psqlodbc 16 lost
Four ArcadeDB findings from September were fixed on main within days and verified here on
snapshot builds, with the release line left open: "ships in 26.10.1". ArcadeDB has released
three times since, 26.10.1 on 2026-10-05, 26.10.2 on 2026-10-15 and 26.11.1 on 2026-11-04,
so on 2026-11-07 the same probes ran again on the release images, pulled from Docker Hub
(26.11.1 is digest 22a04989). This note closes the four lines, records a fifth defect that
was fixed without a report, and one new finding that the retest itself produced.
The four fixes, in a release
| Finding | Fix | On the 26.11.1 release |
|---|---|---|
#7178: the Arrow PostgreSQL ADBC driver could not connect (pg_type bootstrap answered with zero columns) |
#7179, #7187 | connects, GetObjects and GetTableSchema correct |
#7188: no COPY (…) TO STDOUT, the driver's default read path |
#7398, #7607 | the thorough read passes every step with the driver's defaults: an empty result set, one row, 10,000 rows in one binary COPY, a NULL in every column, non-BMP text, the right Arrow types |
#7815 (ours): BEGIN answered with a zero-field RowDescription |
merged 2026-09-17 | at the wire level BEGIN, COMMIT and ROLLBACK answer a bare CommandComplete; on 26.9.1 the RowDescription(0 fields) is still visible in front of it |
#8090: a space-and-fraction timestamp stored as NULL |
#8096 | '2024-02-29 13:45:10.123456' and a bound datetime both round-trip to the microsecond through psqlodbc 18; 'not-a-timestamp' is refused with SQLSTATE 22023; the column reaches Arrow as timestamp[us] |
All four are in 26.10.1 and stayed fixed through 26.10.2 and 26.11.1. The native-driver run is the same script as the 2026-09-15 verification, the timestamp run the same as the 2026-09-22 retest, on the same machine.
A fifth defect, fixed without a report
The 2026-09-22 retest had found one more thing and kept it back for a fix pull request: a
DATETIME_MICROS value before 1970 with a fractional second read back one second late
(1850-06-01T12:00:00.123456 came back as 12:00:01.123456). On 26.11.1 it reads back exactly,
on the text path and through binary COPY, for every fraction width and offset tried, and
1969-12-31T23:59:59.999999 no longer crosses into 1970. ArcadeDB's own DateUtils work in
October covered it, so the draft is retired unfiled.
What the retest found: psqlodbc 16 cannot connect any more
The first run of the timestamp probe on 26.11.1 did not get as far as a query. psqlodbc 16, the
build Debian and Ubuntu package, failed in SQLDriverConnect:
[42601] ERROR: Error on executing query: syntax error in
"SET DateStyle = 'ISO';SET extra_float_digits = 2;show transaction_isolation":
expected SET [SESSION | LOCAL] <parameter> { TO | = } <value>, or RESET <parameter>
That string is psqlodbc 16's connect-time setup, sent as one simple-query message with
three statements in it, which the PostgreSQL protocol allows and PostgreSQL answers with three
results. ArcadeDB runs a simple query as one statement; it never split on ;. On 26.9.1 the
whole string reached the old SET handler, which answered Setting ignored and
CommandComplete SET for anything it did not understand, so psqlodbc was content and moved
on. #8392 (fixed 2026-09-26, in 26.10.1)
rightly made an unparseable SET a syntax error, and from that release on the connect fails.
Checked on the wire, with no driver in between:
26.9.1 26.10.1 / 26.10.2 / 26.11.1
"SET DateStyle = 'ISO';SET extra_float_digits = 2;show transaction_isolation"
DataRow('Setting ignored'), ErrorResponse(42601)
CommandComplete(SET)
"SET DateStyle = 'ISO'" CommandComplete(SET) CommandComplete(SET)
"show transaction_isolation" RowDescription, DataRow, CC RowDescription, DataRow, CommandComplete(SHOW)
"SELECT 1;SELECT 2" syntax error syntax error
psqlodbc 18 is not affected: it asks SHOW DateStyle; first and only sends a SET when the
answer is not ISO, and ArcadeDB's answer is ISO. The 18.00.0004 build connected to 26.11.1
first time and ran every probe above. Through adbcBridge the default delegation setting
(auto) hands a psqlodbc connection string to the Arrow PostgreSQL ADBC driver, which never
sends the string either, so the bridge connected on every release while psqlodbc 16 on its own
did not; the matrix entry runs with delegation off, so there the ODBC build matters.
Until ArcadeDB answers a multi-statement simple query the way PostgreSQL does, the ways through are psqlodbc 18, or adbcBridge with delegation left on its default. A report with the wire-level evidence above is prepared for ArcadeDB.
What this changes in the matrix
The ArcadeDB row keeps its 26.9.1 measurements and now says which releases carry the fixes and which psqlodbc build to use with them; the tracker has the four lines flipped to "fixed in ArcadeDB 26.10.1" and the new finding recorded.