Driving 53 databases through one driver across three operating systems turns up defects that belong to other projects. This file is the record: what was found, where it was reported, and what is documented here but not yet filed. Each reported entry stands on evidence that anyone can reproduce without adbcBridge in the stack; the not-yet-reported table records what the compatibility run observed, and each item is verified the same way before it is filed.
| Date | Project | Report | What it is | Status |
|---|---|---|---|---|
| 2026-09-17 | ArcadeDB | ArcadeData/arcadedb#7815 | PostgreSQL wire, simple query protocol: BEGIN, COMMIT, ROLLBACK and the savepoint statements are answered with a zero-field RowDescription before the CommandComplete, so libpq reports PGRES_TUPLES_OK instead of PGRES_COMMAND_OK; psql prints an empty table after BEGIN and the Arrow PostgreSQL ADBC driver, whose DB-API starts with autocommit off, fails [libpq] Failed to begin transaction:. psqlodbc ignores the status, so adbcBridge was never affected. Sent as a fix with a wire-level test |
fixed on main — our fix PR was merged by the maintainer on 2026-09-17, the day it was opened (merge 7ed83075); found on 26.10.1-SNAPSHOT while re-checking #7188; the new test fails before the fix, and the maintainer re-ran the PostgreSQL module's integration suite on it (244 tests, 0 failures) and extended the fix so a prefixed {sql}BEGIN gets its command tag too. That savepoint statements are accepted without being implemented is tracked separately as ArcadeData/arcadedb#7846. Expected in 26.10.1 |
| 2026-09-17 | DuckDB ODBC | duckdb/duckdb-odbc#524 | Parameter arrays on 1.5.5 and on main: with SQL_ATTR_PARAMSET_SIZE above 1, every fixed-length parameter receives set 0's value in every row under SQL_SUCCESS with the right processed count; only character and binary parameters step (the fixed-length branches read from the start of the bound buffer). Sent as a fix: each set reads its own element, with a test over six types and a NULL set |
merged 2026-09-17 (ours) — approved ("Thanks for the PR! Looks good to me.") and merged by a DuckDB maintainer the day it was opened (merge 1e065eaf), green on Linux, macOS and Windows on both architectures; reproduced on the 1.5.5 release and on main, verified on a build of the fix, where the driver's whole test suite passes. Ships in the first duckdb-odbc release after v1.5.5.0; adbcBridge keeps binding row by row for DuckDB until then |
| 2026-09-17 | DuckDB ODBC | duckdb/duckdb-odbc#523 | SQLGetInfo(SQL_DBMS_VER) on 1.5.5: under unixODBC the process segfaults (the driver's internal SQLAllocHandle call binds to the driver manager, fails, and the error path frees an uninitialized handle); linked directly it returns SQL_SUCCESS, the right length and an empty string (read into one buffer, returned from another). Sent as a fix: the version comes straight from the engine, with a test against pragma_version() |
merged 2026-09-17 (ours) — approved ("Thanks for the PR! It looks good to me.") and merged by a DuckDB maintainer the day it was opened, green on Linux, macOS and Windows; reproduced on the 1.5.5 release and verified on a build of the fix, where the driver's whole test suite passes. Ships in the first duckdb-odbc release after v1.5.5.0 |
| 2026-09-15 | pandas | pandas-dev/pandas#68178 | Documentation contribution: an ADBC-over-ODBC entry for the I/O guide's ADBC section, showing read_sql through adbcBridge. Opened 2026-09-05 |
closed 2026-09-15 by a maintainer: that page is for long-established, common usages, which a driver released three weeks earlier is not yet; acknowledged on the PR, to be revisited with usage numbers in a year |
| 2026-09-15 | Polars | pola-rs/polars#29176 | Documentation contribution: an ADBC-over-ODBC snippet for the user guide's database page. Opened 2026-09-05 | open — no reviewer yet; the pandas page's bar for established usage may apply here too |
| 2026-09-15 | conda-forge | conda-forge/staged-recipes#34738 | Packaging contribution: a libadbcbridge + adbcbridge recipe for Linux and macOS. Opened 2026-09-05 |
open — linter and Linux/Windows builds pass, awaiting a reviewer; nudge due around 2026-09-21 |
| 2026-09-15 | omniload | panodata/omniload#362 (from the maintainer's request in #138) | A fourth --sql-backend, adbcbridge, for omniload's SQL sources: dlt's registered table-loader hook, SQLAlchemy reflection and query compilation kept, Arrow batches read through the database's ODBC driver via adbcBridge; the ODBC connection string derived from the source URI for PostgreSQL, SQL Server, CrateDB and MySQL, --sql-odbc-uri for the rest; tests on PostgreSQL 18, CrateDB 5.10.11 and SQL Server 2025/2022, a handbook page and changelog entry. Contribution rather than a report: the first integration requested from outside |
merged 2026-09-17 — approved by both maintainers (2026-09-15 and 2026-09-17), the second review's five notes addressed on the branch the same day, merged by the maintainer as cb49538 ("Perfect. Thank you so much!"); adbcBridge is now the fourth --sql-backend in omniload's codebase, pinned at 0.1.3 or later, and shipped the same day in omniload v0.17.0 ("Your contribution was included in v0.17.0, thank you again") |
| 2026-08-25 | unixODBC | lurcher/unixODBC#239 | The driver manager overwrites its own stack and heap, and the process aborts, on the first SQL_ERROR from a driver whose SQLWCHAR is 4 bytes (extract_diag_error_w, SQLWCHAR sqlstate[6]). Reproduces on 2.3.12 and 2.3.14. Filed with a driver-independent reproduction: a 40-line fake driver compiled with SQL_WCHART_CONVERT triggers it on Linux, its 2-byte twin does not; plus lldb frames from two real macOS drivers and a fix suggestion. Same crash as the earlier #227 (Informix), which had been closed without a reproduction. |
closed (not planned) by the maintainer on 2026-08-25, who then committed a mismatch check the same day (a2acae7: doubled buffers, sentinel test, message before abort) — the crash is now caught rather than silent; a follow-up with a test table and a patch (report the mismatch as a diagnostic instead of aborting; prime the sentinel on the ODBC 2 path) was posted on the closed issue |
| 2026-08-25 | OpenLink Virtuoso | openlink/virtuoso-opensource#1469 | The macOS driver (Homebrew 7.2.17) is built to iODBC's 4-byte SQLWCHAR and nothing says so; through unixODBC every application dies on its first SQL error. Asks for a unixODBC-width build or a documented iODBC-only statement; includes the UTF-8 statement-literal question. |
open |
| 2026-08-25 | Dremio / Arrow Flight SQL ODBC | dremio/warpdrive#16 | The Apple Silicon build 0.9.7 is iODBC-width, undocumented, and aborts under unixODBC on any SQL error (three servers); LogEnabled=true makes SQLAllocHandle(ENV) fail with IM004 (an uncaught exception in the logger); the pkg ships arrow-odbc.ini.orig but no arrow-odbc.ini; the docs contradict themselves on Apple Silicon support. |
open |
| 2026-08-28 | Firebird ODBC (OdbcFb) | FirebirdSQL/firebird-odbc-driver#299 | Column-wise parameter arrays step fixed-length C types (SQL_C_SLONG, SQL_C_SBIGINT, SQL_C_DOUBLE, dates, timestamps) at the BufferLength stride, which the specification says is ignored for those types; every row receives row 1's values and the NULL indicator lands in the wrong row, with SQL_SUCCESS throughout. SQL_C_CHAR arrays are correct. Filed with three plain-ODBC C programs; reproduces on 3.0.1 and 3.5.0-rc1; row-wise binding works around it. |
fix PR #308 by F.D. Castel (2026-09-07): the input side now derives the stride from the C type when BufferLength is 0, as the output side always did, and the array executor is chosen at execute time; verified on Linux/unixODBC/Firebird 5.0.4 with its CI build on 2026-09-07 — both programs from the report store five distinct rows for every C type, NULL in the right row (the release build had also moved a SQL_C_CHAR NULL from row 3 to row 1). adbcBridge keeps no_param_arrays for OdbcFb until a release carries the fix (the maintainer is collecting the rc2 merge order in #312) |
| 2026-08-28 | Firebird ODBC (OdbcFb) | FirebirdSQL/firebird-odbc-driver#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 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 | 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 (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 | 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 | 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 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 | 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. |
fixed on master, both halves — the SQL_NULL_DATA half is fixed by our fix PR ClickHouse/clickhouse-odbc#586, opened 2026-09-18 and merged 2026-09-24 by the maintainer (slabko), merge commit eb0fdb2654: a helper that treats a parameter as NULL when the value pointer is null or the indicator is SQL_NULL_DATA, used at both sites in driver/statement.cpp, with two unit and two integration tests that failed on master. Not in a release: the reproducer was re-run against 1.5.5.20260810 on 2026-09-24 against ClickHouse 26.7.5.10 and still shows all five problems, so the shipped-in line waits for the next tag. The parameter-array half is a separate mechanism (SQLMoreResults reports result sets, not parameter sets) and is fix PR #588 (ours), opened 2026-09-24: SQLExecute now sends every set of a statement that returns no result set, and stops at the first set that does, so a SELECT keeps handing result sets back one per SQLMoreResults. The maintainer's review (2026-09-25) asked for the ODBC error-path contract, added the same day: SQL_ATTR_PARAMS_PROCESSED_PTR counts the failing set and SQL_ATTR_PARAM_STATUS_PTR reads {SUCCESS, SUCCESS, ERROR, UNUSED, UNUSED} on his five-set case, with both cases as tests; verified against ClickHouse 26.7.5.10 on a driver built from the branch, 391 of 392 of the project's own tests passing (the one failure needs CREATE USER and fails the same way on 1.5.5). Approved and merged 2026-09-29 by slabko, merge commit 74027bcf6e; master is exactly the verified branch plus that merge commit, so the branch run stands for master. Neither half is in a release yet (latest tag 1.5.5.20260810), so the matrix keeps parameter arrays off for the shipped driver; both lines become "fixed in " when a tag carries them. The issue stays open for that |
| 2026-08-29 | clickhouse-odbc | ClickHouse/clickhouse-odbc#335 (comment) | 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. |
fixed 2026-09-15 — ClickHouse/clickhouse-odbc#585 (SQLRowCount → −1, the ODBC "unknown", where 1.5.5 answered 0) was opened and merged the same day, with a second maintainer's approval, and #335 closed as completed after five years. Verified on the PR's CI build and on the merged master build against ClickHouse 26.7.5.10: −1 after a literal INSERT and after a DELETE, the full ClickHouse compatibility entry unchanged. Ships in the first release after v1.5.5.20260810. The maintainer's reasoning, 2026-09-15: 0 was wrong and −1 is the honest value; written_rows from X-ClickHouse-Summary is not usable as an exact count because it is untrusted while async_insert is on (ClickHouse/ClickHouse#57768) and, as he then noted and we confirmed, it also counts rows written to materialized views (3 rows through INSERT … SELECT with two views reported 7), so −1 is the final answer |
| 2026-08-29 | OpenLink Virtuoso | openlink/virtuoso-opensource#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 |
| 2026-08-29 | OpenLink Virtuoso | openlink/virtuoso-opensource#1471 | Any Charset= value but the exact literal UTF-8 aborts the process inside SQLDriverConnect (GPF: Dkbox.c:638 Double free), including every charset Virtuoso itself lists; Charset=UTF-8 connects but returns wide columns doubly encoded with the original byte length in the indicator. |
open — the abort sent upstream as a fix, openlink/virtuoso-opensource#1477 (ours, opened 2026-09-18): the cause is a double free, not a compare — con_charset_name aliases the parsed option buffer and two owners release it; the fix gives it a box of its own (libsrc/Wi/CLIsql3.c, +8/−1), after which every charset connects and an unknown one gets the intended CL035 warning. The doubly encoded wide columns under Charset=UTF-8 stay open |
| 2026-08-29 | OpenLink Virtuoso | openlink/virtuoso-opensource#1472 | SQL_C_SBIGINT parameters store 0 and SQL_C_SBIGINT fetches return indicator 0 with the buffer untouched (only text declared SQL_NUMERIC/SQL_DECIMAL converts exactly); SQL_C_SLONG parameters are read as 8 bytes regardless of BufferLength. |
open |
| 2026-08-29 | OpenLink Virtuoso | openlink/virtuoso-opensource#1473 | A column-wise SQL_C_TYPE_DATE parameter array is stepped by SQLBindParameter's ColumnSize rather than by sizeof(SQL_DATE_STRUCT): ColumnSize 0 inserts row 0's date into every row, other values insert garbage dates, all SQL_SUCCESS. |
sent upstream as a fix, openlink/virtuoso-opensource#1478 (ours, opened 2026-09-18): sqlc_sizeof_1() in libsrc/Wi/CLIuti.c lists the ODBC 2 names SQL_C_DATE/TIME/TIMESTAMP but not the ODBC 3 SQL_C_TYPE_* ones, so those fall to ColumnSize; the fix adds the three names under ODBCVER >= 0x0300 as the file's other switches do, verified on a driver built from develop/7 |
| 2026-08-29 | MySQL Connector/ODBC | mysql/mysql-connector-odbc#20 | SQLDescribeCol describes a DATETIME(6) column as COLUMN_SIZE 19 / DECIMAL_DIGITS 0 (values are 26 characters; a buffer sized from the description gets 01004), and SQLColumns reports COLUMN_SIZE NULL for date/datetime; MariaDB Connector/ODBC describes the same column 26/6. Filed on the GitHub mirror (bugs.mysql.com account could not be created). A plain-ODBC probe on 2026-09-04 added the consequence and the root cause for a follow-up: SQLGetTypeInfo reports datetime as COLUMN_SIZE 21 / MAXIMUM_SCALE 0, so a client sizing its bind from the type table (pyodbc) stores 13:45:10.123456 as 13:45:10.1 — byte-identical against MySQL 8.4 and SingleStore 9.1, NO_SSPS=1 or not. |
open |
| 2026-08-29 | MySQL Connector/ODBC | mysql/mysql-connector-odbc#21 | SHOW VARIABLES/SHOW COLLATION against a MySQL-wire server reporting a zero character-set width (MatrixOne 4.2.0) kill the client with SIGFPE in get_column_size() (utility.cc) during SQLExecDirect, before any fetch; the same statement against MySQL 8.4.11 is fine. gdb backtrace included. |
open |
| 2026-08-29 | Apache Ignite ODBC | apache/ignite#13537 | Column-wise parameter arrays test the NULL indicator of row 0 for every row: a SQL_NULL_DATA below row 0 stores an empty string (VARCHAR) or segfaults the client inside SQLExecute (BINARY, WriteInt8Array handed the -1 as a length); a NULL in row 0 nulls the whole batch; row-wise binding refused. parameter.cpp cited, fix suggested. |
open — fix PR #13610 (ours), opened 2026-09-23: the indicator was read from the un-offset buffer in modules/platforms/cpp/odbc/src/app/parameter.cpp, before the row offset was applied, so it came from a different row than the value; a negative length also reached memcpy in the binary branch. Both offsets are now applied before the indicator is tested, and a negative binary length is written as NULL. Carries a unit test for app::Parameter, which had none, covering the current-row indicator for character, binary and integer parameters, a NULL in row 0, a NULL below row 0 and the negative-length case; it needs no server. The reproducer was re-run against a build with the change and all three rows round-trip. The issue itself has had no reply since it was filed. Ignite asks for an ASF JIRA ticket and an IGNITE-NNNNN title for code changes: rather than invent a number the pull request says so openly, and contributor access has been requested on dev@ignite.apache.org so the ticket can be filed and the title corrected |
| 2026-08-29 | OpenSearch SQL ODBC | opensearch-project/sql-odbc#101 | Any character value converted to SQL_C_TYPE_TIMESTAMP/SQL_C_TYPE_DATE comes back as today's date under SQL_SUCCESS (convert.c fills an unparsed SIMPLE_TIME from localtime); a TIMESTAMP literal takes the same path because the result-set type map lacks timestamp. |
open — fix PR #105 (ours), opened 2026-09-24: the character source types go through timestamp2stime() before the output switch and a string it cannot read returns COPY_INVALID_STRING_CONVERSION, which had no SQLSTATE and now maps to 22018. Syntax-checked under GCC with no new diagnostics; not built here (the project's CMake hardcodes a 2019 kernel-headers path and its tests need vcpkg, the AWS SDK and a live cluster), so its CI is the first real run. DCO check green |
| 2026-08-29 | OpenSearch SQL ODBC | opensearch-project/sql-odbc#102 | SQLError/SQLErrorW return the same connection error on every call and never SQL_NO_DATA, so unixODBC's SQLDriverConnect(W), which prefers SQLError for a failed connect's diagnostics, spins forever on any failed connect (closed port, useSSL mismatch, bad auth=); SQLGetDiagRecW is correct, and psqlodbc avoids it by not exporting SQLError. |
open — fix PR #104 (ours), opened 2026-09-24: OPENSEARCHAPI_ConnectError now clears the connection error after reporting it, as EN_get_error() already does for the environment, so the ODBC 2 one-shot contract holds and the driver manager's loop reaches SQL_NO_DATA_FOUND; cleared after the last use of the message it points at, and not on the buffer-sizing retry path. Four lines. Same build caveat as #105; DCO check green |
| 2026-08-29 | QuestDB | questdb/questdb#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 |
| 2026-08-29 | QuestDB | questdb/questdb#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, by a community contributor, reviewed 2026-09-27 by the project's founder (bluestreak01): approve with comments, two changes asked of the author before merge. The review also found, from instrumented runs, that with the fix DEALLOCATE ALL succeeds but releases nothing — it is parsed as DEALLOCATE "ALL", a lookup for a statement of that name, so prepared statements survive it and re-preparing the same name fails with duplicate statement (his A2, not yet filed; he offered to). That is the part this project cares about, since drivers and pools send DEALLOCATE ALL as a session reset: our report covered the error, not what happens with statements present. Watching for the issue; our reproduction and the pooling impact go on it as the reporter of the parent |
| 2026-08-29 | CrateDB | crate/crate#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 merged 2026-08-31, ships in 6.4.4 |
| 2026-08-29 | psqlodbc | postgresql-interfaces/psqlodbc#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 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, 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 | 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 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's own half, MaterializeInc/materialize#38606, merged 2026-09-14 and verified with this program the same day (see the Materialize row). 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 (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. |
fixed on main — MaterializeInc/materialize#38606 by antiguru (Materialize), merged 2026-09-14 (9adca52d); unquotes prepared-statement, portal and cursor names before lookup. Verified the same day on the v26.43.0-dev.0--main.g9adca52d image with the #208 program and psqlodbc 18.00.0004, Protocol=7.4-0: a statement freed before the commit keeps both rows (2/2), where the Aug 19 latest image loses both with the same driver and the stock 16.00 driver loses both on either server; results posted on the PR. Not in a Materialize release yet |
| 2026-09-04 | SingleStore Connector/ODBC | memsql/singlestore-odbc-connector#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. |
fixed — fix PR #48 (ours), opened 2026-09-17, approved and merged 2026-09-23 by the maintainer (Pavlo Mishchenko), merge commit 182ae5b515, closing the issue the same minute: single-quoted literals in the template, with a test under ANSI_QUOTES. Verified against SingleStore 9.1.1, and the driver was rebuilt from the merged branch here on 2026-09-23 with the whole info suite green in both the client-side and the server-side prepared-statement modes. Review asked for the test to run on its own connection, following the project's odbc143, and to restore sql_mode before disconnecting; both landed in the second commit. Not yet in a release: master is still 1.2.2, so the shipped-in line waits for the next tag |
| 2026-09-05 | ArcadeDB | ArcadeData/arcadedb#7178 (opened by the maintainer from the discussion follow-up) | 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, 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 carried the driver's exact statements; its GetTableSchema item (the ::regclass cast) is fixed in #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, implemented in #7398 on 2026-09-10 and framed like PostgreSQL's in #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 (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 (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 with both servers' chunk dumps on 2026-09-12) was fixed by the maintainer in ArcadeData/arcadedb#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 | 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. |
fixed — fix PR #47 (ours), opened 2026-09-17, approved and merged 2026-09-23 by the maintainer (Pavlo Mishchenko), merge commit e760503629, closing the issue the same minute and with no changes requested: TABLE_CAT NULL instead of strdup(NULL) in SQLColumns and SQLPrimaryKeys, with a test in test/catalog2.c for the connection shape that triggered it. Verified against SingleStore 9.1.1. Not yet in a release: master is still 1.2.2, so the shipped-in line waits for the next tag |
| 2026-09-21 | ArcadeDB | ArcadeData/arcadedb#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 |
fixed in #8096, merged 2026-09-22 by the project (Luca Garulli), who had filed the issue on 2026-09-21 as severity:critical, crediting the report and naming the root cause. The space-and-fraction form is now accepted, and a value no parser can read fails the write with an error naming it instead of storing NULL; reads stay lenient and return NULL. Verified here on 26.10.1-SNAPSHOT (build 382ae09d, 60 commits past the merge) on 2026-09-22: the literal and the bound parameter both round-trip to the microsecond, an unreadable value raises SQLSTATE 22023 through psqlodbc, and the column now reaches Arrow as timestamp[us] rather than a string. Awaiting the 26.10.1 release. ArcadeDB published an account of this and the three earlier findings on 2026-09-21: arcadedb.com |
Each of these is recorded with its first error and the conditions in
COMPATIBILITY.md and the per-OS benchmark files; reports follow as
time allows, and a reproduction contributed by anyone is welcome.
| Project | Finding | Where recorded |
|---|---|---|
| psqlodbc (16 and 18) | Its SQL_C_CHAR conversion of a timestamptz column renders the session's wall-clock time and drops the offset the server sent (2024-02-29 08:45:10.123 for 08:45:10.123-05), and a bound SQL_TYPE_TIMESTAMP parameter is sent as a zone-less literal the server reads in the session zone; a client that wants instants must therefore run its sessions on UTC. Found 2026-09-15 on a PostgreSQL 16 cluster set to America/New_York; adbcBridge 0.1.3 runs SET TIME ZONE 'UTC' at connect (adbc.odbc.utc_session). Candidate for a psqlodbc report once the driver's intended behaviour for SQL_C_CHAR on timestamptz is checked against its USE_ZONE build option |
docs/reference/quirks.md psqlodbc row; notes page |
| MariaDB Connector/ODBC ≥ 3.2 (Connector/C 3.4.9) | A parameter array with a NULL DATE segfaults the connector; the array path also misreports MySQL's row count. adbcBridge routes those versions row by row (no_param_arrays). |
bench/BENCHMARKS-macos.md batch 2 |
| MariaDB Connector/ODBC 3.2.9 | Its connect-time probe SELECT 1 FROM DUAL WHERE @@sql_mode LIKE '%ansi_quotes%' fails on servers without a DUAL table (Databend, GreptimeDB); its prepared/binary-literal path fails on Doris and StarRocks. |
COMPATIBILITY.md, macOS column |
| MariaDB Connector/ODBC 3.2.9 (macOS arm64) | Every MySQL-wire server reads at 39–47k rows/s through it, in five languages and pyodbc alike, against 1.3–4.5M rows/s through MySQL's own connector on the same machine. | bench/BENCHMARKS-macos.md batches 3–4 |
| MySQL Connector/ODBC 8.4.0 (Windows) | Needs NO_SSPS=1 against every non-MySQL server (No data supplied for parameters in prepared statement); reads result sets from servers without character-set session variables as 3-byte utf8, so astral characters come back as ??? (Databend, GreptimeDB, MatrixOne, MongoDB BI). Connector/ODBC 26.7.1 for Windows reads astral characters correctly but still needs NO_SSPS=1 against non-MySQL servers. |
bench/BENCHMARKS-windows.md |
| MySQL Connector/ODBC 26.7.1 (macOS arm64, iODBC build) | Writes UTF-16 code units into iODBC's 4-byte SQLWCHAR (surrogate pairs as two units) but does not read bound SQL_C_WCHAR parameters in four-byte units consistently — plain ASCII inlined as garbage. adbcBridge binds text narrow for it on a four-byte build. Only obtainable through a JavaScript download page. |
docs/TROUBLESHOOTING.md, bench/BENCHMARKS-macos.md batch 4 |
| Arrow Flight SQL ODBC (Windows build) | Returns a non-BMP character with only its low 16 bits (U+1F680 → U+F680) when building UTF-16 — on literals and stored data, through pyodbc and the bridge identically (sqlflite, InfluxDB 3). | bench/BENCHMARKS-windows.md |
| taos-odbc (TDengine, Windows build) | An ANSI build whose iconv lacks the CP1252 → UTF-8 table: statement text from the driver manager cannot be converted, so nothing executes. |
bench/BENCHMARKS-windows.md |
| MariaDB Connector/ODBC 3.1.15 (Linux) | SQLBindCol(SQL_C_CHAR) does not NUL-terminate: a value that exactly fills the buffer returns SQL_SUCCESS with no terminator and no 01004, and a shorter buffer gets the data bytes with no terminator (SQLGetData on the same value is correct); SQLSetPos(SQL_POSITION, n) answers SQL_SUCCESS and a following SQLGetData returns row 1's data for every n; a fractional-second TIME string bound SQL_C_CHAR → SQL_TYPE_TIME is refused with 22008 Datetime field overflow even into TIME(6). adbcBridge reads bound columns by their indicators and already sets getdata_repair=false for this driver. |
tests/compat/README.md, MariaDB section |
| MatrixOne 4.2 | A parameter array bound into a BIT column aborts the server once it holds NULLs (malloc(): unaligned fastbin chunk detected; six sets with two NULLs is enough, while single parameters, NULL-free arrays and the same array into TINYINT are fine); over server-side prepared statements a bound NULL into BIT is stored as false (NO_SSPS=1 stores NULL); SQLDescribeCol sizes a TEXT column at one third of its widest value's byte length; SQLColumns reports DATA_TYPE 0 for every column. adbcBridge: booleans ingested as TINYINT, no-declared-length columns bound at long_bind_bytes. — fixed on main by matrixorigin/matrixone#27645 (2026-08-26, issue #27635) before this could be filed; verified against the 2026-08-28 nightly, the released 4.2.0 still aborts. |
COMPATIBILITY.md, tests/compat/README.md |
| Arrow Flight SQL ODBC 0.9.7 (Linux x86_64) | SQLGetFunctions reports SQLBindParameter and SQLNumParams as supported while SQLBindParameter always answers HYC00 (only SQLDescribeParam tells the truth); SQL_ATTR_AUTOCOMMIT = OFF is HYC00, so there is no transaction control; the SQLColumns crash recorded above for sqlflite and InfluxDB 3 does not reproduce against Dremio 26. |
tests/compat/README.md, Dremio section |
OpenLink Virtuoso (virtodbc.dll 7.2.17, Windows) |
Advertises the SQL_GD_* extensions but SQLSetPos(SQL_POSITION) fails on a block cursor; and the bound-column indicator array is written at a 4-byte stride on a block cursor (read at that stride by the ind_stride_32bit quirk). |
bench/BENCHMARKS-windows.md; src/odbc_driver.c (ind_stride_32bit) |
| DuckDB ODBC (Windows, Rust) | Throws a C++ exception through the FFI boundary; a Rust process cannot unwind it and aborts. | bench/LANGUAGE_BENCHMARKS-windows.md |
| 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 |
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 |
| sqliteodbc 0.99991 (Linux) | SQLGetData(SQL_C_NUMERIC) returns a bare SQL_ERROR with zero diagnostic records (the same conversion through SQLBindCol gives HY003 invalid type 2); SQL_ATTR_PARAM_STATUS_PTR is accepted and never written, so a caller reads uninitialised status; a TIMESTAMP written through a bound SQL_C_TYPE_TIMESTAMP is stored with three fractional digits (statement text keeps six); a second SQLGetData on a fully returned column hands back a suffix under SQL_SUCCESS instead of SQL_NO_DATA; SQLRowCount on an open SELECT answers 0. adbcBridge reads decimals as text and timestamps whole. |
tests/compat/README.md, SQLite section |
| MySQL Connector/ODBC 9.4.0 (against MongoDB BI Connector) | Two segfaults with standalone reproductions: SQLColumns crashes in columns_i_s() on the NULL NUMERIC_PRECISION mongosqld's information_schema reports for a DECIMAL column (per column, not per table; NO_I_S=1 is accepted and changes nothing); and the handshake crashes in the bundled libmysqlclient (authsm_begin_plugin_auth, strcmp() on a NULL plugin name) when the server's greeting names no auth plugin and PLUGIN_DIR is unset. adbcBridge: no_sql_columns, PLUGIN_DIR=. |
COMPATIBILITY.md, tests/compat/README.md |
| Arrow Flight SQL ODBC 0.9.7 (Linux) | The SQLColumns segfault has a root cause: arrow::KeyValueMetadata::Get on a null pointer from GetColumns_Transformer::Transform, for any table whose Flight SQL schema carries no per-field key-value metadata — every sqlflite table, InfluxDB 3's system/information_schema tables (its iox tables are fine), never Dremio 26; a request spanning one such table loses the good rows with it, and three system tables answer SQL_SUCCESS with zero rows for tables that have columns. SQLGetFunctions also reports SQLStatistics as supported while the call answers HYC00. One-call reproduction. |
tests/compat/README.md, Flight SQL and InfluxDB sections |
| Oracle Instant Client ODBC 23.9 (SQORA, Linux) | Changing SQL_ATTR_ROW_ARRAY_SIZE on an open cursor is accepted and then either segfaults on a later SQLFetch (bcoReturnColData; LOB or not, at switch points that depend on cursor depth) or silently loses rows (lowering strides the result set, 100,000 rows read back as 13,440-14,336; raising can rewind and re-deliver). SQLGetData on a block cursor answers HY109 although SQL_GETDATA_EXTENSIONS advertises `SQL_GD_BLOCK |
SQL_GD_BOUND; SQL_C_SBIGINTis refused on both sides (parameters silently, reads with 07006) andSQLGetTypeInfo(SQL_BIGINT)is empty; an unconstrainedNUMBERis read through a double and loses precision beyond 2^53. adbcBridge:fixed_rowset, getdata_repair=false, bigint_param_as_string`. |
| Apache Ignite ODBC | The C++ platform layer has only linux/ and win/; the Darwin build stops at sys/sysinfo.h. |
COMPATIBILITY.md, macOS column |
| OpenSearch SQL ODBC | The macOS package is x86_64-only and links /usr/lib/libiodbc. |
COMPATIBILITY.md, macOS column |
| openGauss (enmotech image, arm64) | The MOT engine panics at start inside Docker Desktop's VM (thread identifiers exhausted), with or without enable_numa = false. |
COMPATIBILITY.md, macOS column |
| Spanner emulator | A read-write transaction left open by a killed client wedges the emulator (FATAL: UNAVAILABLE on every later connection). |
COMPATIBILITY.md, Windows column |
SAP HANA client ODBC 2.29 (libodbchdb, Linux, macOS and Windows alike) |
Narrow statement text is decoded as Latin-1, not as the UTF-8 the driver manager hands over: the literal 'héllo 🚀' is stored as eleven characters, so a literal never matches the same value sent as a bound SQL_C_WCHAR parameter; a SQL_C_CHAR parameter is decoded the same way; eleven locale and connection-keyword variations change nothing (unknown keywords are silently accepted), and SQLExecDirectW and SQL_C_WCHAR store it exactly (adbcBridge routes statement text through the W entry points, wide_sql). SQLGetTypeInfo returns all 33 types in alphabetical TYPE_NAME order with DATA_TYPE unsorted, against the ODBC ordering contract, which puts SECONDDATE before TIMESTAMP and BINTEXT before NCLOB, so type-table-driven DDL silently drops fractional seconds. Both reproduced without adbcBridge on 2026-09-04 (C, isql, pyodbc). |
COMPATIBILITY.md (SAP HANA row) |
Exasol ODBC 25.2 / 26.2 (exaodbc, Linux and Windows) |
SQLBindParameter refuses SQL_C_BINARY for any target (HY003), so no binary value can reach the server; a NULL parameter described SQL_DECIMAL — every integer column, since INT/BIGINT are DECIMAL aliases — cannot be bound with SQL_C_DEFAULT (SI002 C-Type not supported, HY010); SQL_GETDATA_EXTENSIONS claims SQL_GD_BLOCK, but on a block rowset only the first SQLGetData after each SQLFetch succeeds — every later one, on any row SQLSetPos(SQL_POSITION) selects, answers SQL_NO_DATA with no diagnostic record — while SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES1 is 0x0 and SQLSetPos still returns SQL_SUCCESS; SQLGetData(SQL_C_BINARY) is also refused (07006). All three reproduced without adbcBridge on 2026-09-04, in C against unixODBC. |
COMPATIBILITY.md (Exasol row) |
Altibase ODBC 7.3 (libaltibase_odbc) |
A SQL_C_WCHAR parameter above the BMP is stored as CESU-8 (a surrogate pair encoded as two 3-byte sequences) while the narrow path stores UTF-8, so the two paths disagree on the same value; SQLGetTypeInfo has no SQL_LONGVARCHAR and reports CREATE_PARAMS "precision" for VARCHAR, so a type-table-driven VARCHAR DDL comes out bare, which Altibase reads as VARCHAR(1); BYTE/VARBYTE/BLOB carry vendor SQL_DATA_TYPE codes (20001, 20003, 30) and fall through to text as hex in a generic reader. Vendor's GitHub carries no source since the 2023 withdrawal of the open-source edition; support channel only. |
COMPATIBILITY.md (Altibase row) |
Kinetica ODBC 7.1.9 (Linux, libKineticaODBC) |
Executes parameter N with the value bound at N+1 and sends the last as NULL, under SQL_SUCCESS with an empty diagnostic queue (a one-parameter INSERT stores NULL; eight parameters fail HY000 (1040) Driver Error: type: %d); SQLDescribeParam reports every parameter SQL_VARCHAR(1024); a string parameter on SELECT ? segfaults the process; a DECIMAL(18,4) column is described three ways (SQLDescribeCol 38/0, SQLColumns 18/18, SQLGetTypeInfo 38). Reproduced through unixODBC with no pyodbc. adbcBridge marks the entry read-only. Server side: a provably false predicate is constant-folded onto SYSTEM.ITER, which cannot project a BYTES column, so WHERE 1=0 fails on any table holding binary (LIMIT 0 does not). |
COMPATIBILITY.md (Kinetica row) |
Kinetica ODBC 7.1.9 (Windows, KineticaODBC.dll, kineticadb/kinetica-client-win-odbc) |
Exports the W entry points but transcodes W statement text through the ANSI code page before sending it: the literal 'héllo 🚀' lands as cp1252 bytes and every later read of the row fails HY000 (50311) ICU conversion, identical through pyodbc; its narrow statement path passes UTF-8 through, its narrow fetch does not. |
COMPATIBILITY.md, Windows column; bench/BENCHMARKS-windows.md |
Actian Ingres ODBC 10.1 (libiiodbcdriver, Linux) |
Its wide entry points take a four-byte SQLWCHAR (typedef wchar_t SQLWCHAR), so under unixODBC — which selects the W path by the presence of SQLConnectW — the connection string arrives as its first character and the connect fails E_GC0138; Driver= is copied into a 32-byte buffer with no bound, so any real path aborts the process (*** buffer overflow detected *** under ConDriverInfo); a UTF-16 surrogate pair in a SQL_C_WCHAR parameter is rejected (5000B). adbcBridge's matrix loads it behind an ANSI-only forwarding shim; a patch for both source defects is prepared and build-tested. No public source repository accepts pull requests; the report goes to Actian's community or support channel. |
COMPATIBILITY.md (Ingres row); tests/compat/fixtures/ingres_ansi_shim.c |
Actian Ingres ODBC 10.1 (libiiodbcdriver, Linux), from .NET |
SQLTables segfaults inside the driver's own IIODsqtb_SQLTables_InternalCall when called from a .NET process (System.Data.Odbc present, libcoreclr.so on the stack), after SQLSetConnectAttr(SQL_ATTR_AUTOCOMMIT) has already failed on the same connection; identical with autocommit on, with the native comparison off and with a 100-row workload, so neither size nor the second client. The same calls from Python, Rust and Go succeed. |
bench/LANGUAGE_BENCHMARKS.md (ingres, csharp) |
Actian Ingres client library 10.1 (libcompat.1.so, Linux), under a JVM |
The client's EX exception facility installs process-wide signal handlers when its GCF layer loads (i_EXcatch → EXsignal → EXsetsig → sigaction) and takes over the SIGSEGV the JVM uses for implicit null checks, so a Java process that has loaded the driver dies # SIGSEGV … (sent by kill) in libcompat.1.so EXsignal within a second, before any ODBC call. A library loaded into a host process should not replace the host's signal handlers. |
bench/LANGUAGE_BENCHMARKS.md (ingres, java) |
| Ingres 10.1 server (logging system) | A single autocommit transaction that inserts 100,000 rows is force-aborted (E_DM9059_TRAN_FORCE_ABORT, client 40001 (4706) … externally aborted) by the log's force-abort limit at the default configuration; 20,000 and 50,000 rows load. Configuration rather than defect; recorded so the empty cell's cause is on file. |
bench/LANGUAGE_BENCHMARKS.md (ingres, python fetch) |
Actian Client 1.5 for Windows (CAIIOD35.DLL) |
Negotiates the server's ISO88591 with Ingres 10.1 (declaring UTF8 is refused, E_GC2462) and substitutes ? for U+1F680 on every route, pyodbc identical — arguably by design, recorded so the Windows cell's reason is on file. |
COMPATIBILITY.md, Windows column |
IBM i Access ODBC 1.1.0.29 (libcwbodbc, Linux) |
The Driver= value is limited to 35 characters (30119 Key value in connection string too long at 36 — one shorter than the driver's own installed path); message catalogues and conversion tables are resolved under a compiled-in /opt/ibm/iaccess, without which every diagnostic degrades to CWBNL0202 - cwbodmsg.dll; a CLOB column can be neither array-bound for writing nor bound for reading, so the type its own SQLGetTypeInfo(SQL_LONGVARCHAR) names costs one round trip per row (8 rows/s). |
COMPATIBILITY.md (Db2 for i row) |
IBM i Access ODBC for macOS 1.1.0.29 (libcwbodbc.dylib, arm64) |
With SSL=1 the driver segfaults inside SQLDriverConnect whenever pyarrow's libraries are loaded in the same process; bisected: bare Python connects, with adbc_driver_manager connects, with the bridge library connects, with pyarrow loaded it crashes on SSL=1 and connects on SSL=0, and pyodbc alone connects on SSL=1. libcwbcore.dylib is two-level with weak definitions and pyarrow's libarrow/libarrow_flight carry their own OpenSSL statically, so weak-symbol coalescing across images is the likely mechanism; the exact symbol is not identified (no debugger on that account, no crash report written). The Linux driver does not show it. The matrix entry runs SSL=0 on macOS. |
COMPATIBILITY.md, macOS column |
| Docker Desktop for Windows (WSL 2.7.12) | The data VHDX never returns space to Windows while running; wsl --shutdown compacts it. |
bench/BENCHMARKS-windows.md |
ADBC Driver Foundry MySQL driver 0.6.0 (adbc-drivers/mysql) |
Against GreptimeDB, reading a table with a DECIMAL(10,3) column fails while building the Arrow schema: invalid decimal precision/scale (1023, 0) — the server describes the column with precision 1023 and the driver passes it through unchecked (MySQL Connector/ODBC reports DECIMAL(10,3) on the same column). Also observed, and arguably by design: the CREATE TABLE it generates for bulk ingest (… INT NULL, … DOUBLE NULL) is a syntax error on Databend and StarRocks, and the statement it prepares on connect is refused by Apache Doris (Only support prepare SelectStmt or InsertStmt now), so those three MySQL-wire servers are unreachable through it. Probe of 2026-09-05. |
Native ADBC drivers on wire-compatible databases |
Apache Arrow ADBC PostgreSQL driver 1.12.0 (adbc-driver-postgresql) |
Not a defect, recorded so nobody re-measures it: the driver reads every result through COPY … TO STDOUT (FORMAT binary) and bootstraps its types from pg_catalog.pg_type, so on servers that speak the PostgreSQL wire protocol without those two — CockroachDB, CrateDB, YDB, openGauss (binary row decode), Materialize, QuestDB, RisingWave, ArcadeDB (bootstrap query) — it initializes and then fails on the first result set, or fails at connect; on Cloud Spanner's PGAdapter its ingest creates a table without the primary key Spanner requires. Probe of 2026-09-05; the same finding is what adbcBridge's own delegation probe (0.1.1) tests for. Re-measured 2026-09-06 with the driver's adbc.postgresql.use_copy=false statement option: CockroachDB and openGauss then pass all seven steps natively; CrateDB reads but its COPY … FROM STDIN grammar and the $1::regclass::oid schema lookup still stop ingest and GetTableSchema; YDB returns every column as an opaque binary extension type because its pg_type does not describe its types the way the resolver needs. |
Native ADBC drivers on wire-compatible databases |