OpenSearch SQL ODBC takes both fixes in one evening, and its Linux build arrives on its own
The two findings from August (the note) each went upstream as a pull request on 2026-09-24. On 2026-11-03, within six seconds of each other, the maintainer approved and merged both, with "Thanks!" as the whole review:
- #105: a character value that is
not a datetime now fails with
22018instead of arriving as today's date underSQL_SUCCESS. Closes #101. - #104:
OPENSEARCHAPI_ConnectErrorclears the connection error once it has reported it, so unixODBC'sSQLErrorloop reachesSQL_NO_DATAand a failed connect returns instead of spinning. Closes #102.
Verified on the merge commit
The project publishes no Linux build, so the check is a build of main at 8be890e here, with
the three reproducers from the two issues rerun against it and against the 1.5.0.0-era build
they were written on:
| Reproducer | Before | At 8be890e |
|---|---|---|
SELECT 'hello' read as SQL_C_TYPE_TIMESTAMP |
SQL_SUCCESS, today's date |
SQL_ERROR, 22018 invalid string conversion |
SELECT '12.345' read as SQL_C_TYPE_DATE |
SQL_SUCCESS, today's date |
SQL_ERROR, 22018 |
SELECT '2024-02-29 13:45:10.123' as a timestamp |
today's date | 2024-02-29 13:45:10.123 |
SQLDriverConnectW to a closed port, through unixODBC |
never returns, 100 % CPU | returns in 2 s with 08001 |
SQLErrorW after the failed connect, called three times |
the same 08001 every time |
SQL_NO_DATA once the record is reported |
The POSIX branch compiles upstream now
The earlier note listed five things in the way of a Linux build, three of them real bugs, the
worst a sem_init() given capacity where the other platforms pass initial, so the result
queue's pop semaphore started full and the first close() segfaulted. None of that was filed:
it was documented and the compatibility entry was built with local patches.
The maintainer's own #110, merged a few
hours before the two fixes, takes care of all of it: -Werror becomes an option
(WARNINGS_AS_ERRORS, off in a new build_linux_release64.sh), the semaphore constructor and
sem_timedwait() call are corrected, sem_init() gets initial, and a Linux build joins the
project's CI. Building 8be890e here needed no local patch at all. One thing to know if you
build it yourself: that commit still keeps the vendored rapidjson on the include path only on
Windows, so pass -DCMAKE_CXX_FLAGS=-I<tree>/libraries/rapidjson/include; the commit after it
(#113) moves rapidjson to vcpkg on
every platform.
What is left: the type map
105 fixes the conversion of a character value. It does not touch the second path the August
note described: the result-set type map in opensearch_parse_result.cpp has no entry for the
plugin's timestamp type name, so GetSchemaInfo() falls back to SQL_WVARCHAR. OpenSearch
3.9 reports every date-mapped column under that name, so after #105 such a column arrives as
text rather than as today's date, which is better, but still not a timestamp. SQLColumns and
SQLGetTypeInfo map the same name to SQL_TYPE_TIMESTAMP, so the two metadata paths still
disagree about the same column.
The fix is two lines, the missing entry plus a duplicate date key that an unordered_map
ignores, and is open as #115.
Checked on the same build against OpenSearch 3.9.0: SELECT TIMESTAMP '2024-02-29 13:45:10' and
a date-mapped index column are described as SQL_TYPE_TIMESTAMP (93) and convert to that
instant; through adbcBridge the column goes from string to timestamp[us].
No release carries any of this yet; the project's only release is still 1.5.0.0 from 2023. The OpenSearch entry in the compatibility matrix and the upstream record move to "fixed in" that version when one appears.