{
 "as_of": "2026-09-01T11:43:58Z",
 "window_days": 7,
 "count": 24,
 "with_project_activity": 8,
 "fixed": 1,
 "items": [
  {
   "project": "unixODBC",
   "repo": "lurcher/unixODBC",
   "number": 239,
   "url": "https://github.com/lurcher/unixODBC/issues/239",
   "title": "Driver manager overwrites its stack/heap and aborts on the first SQL_ERROR from a driver whose SQLWCHAR is 4 bytes (extract_diag_error_w) — driver-independent repro",
   "reported": "2026-08-25",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "closed (not planned)",
   "closed_at": "2026-08-25T08:16:35Z",
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "comment",
     "at": "2026-08-25T08:16:35Z",
     "actor": "lurcher",
     "association": "owner",
     "text": "While I understand the problem described. I am still not sure its something that needs fixing. I would argue (and I am happy to be wrong) that in this case, its not the DriverManager that is overwriting its own stack, its the driver, and whatever the DM does, it can't (well I guess it could, but it would require far more effort that is practical) mitigate against a driver doing something wrong, wh…",
     "url": "https://github.com/lurcher/unixODBC/issues/239#issuecomment-5407471505"
    },
    {
     "type": "closed",
     "at": "2026-08-25T08:16:35Z",
     "actor": "lurcher",
     "reason": "not_planned",
     "commit": null
    },
    {
     "type": "comment",
     "at": "2026-08-25T15:03:47Z",
     "actor": "kadler",
     "association": "contributor",
     "text": "@lurcher Alternatively this feature could use an odbcinst.ini setting, which doesn't require changing every driver to support.",
     "url": "https://github.com/lurcher/unixODBC/issues/239#issuecomment-5412422672"
    },
    {
     "type": "comment",
     "at": "2026-08-25T15:17:40Z",
     "actor": "lurcher",
     "association": "owner",
     "text": "Yes that's true, the only reason I thought about the driver reporting it is that it could be tied to how the driver was built, in the ini file, someone could just set it to a value that seems to work, but was actually wrong. I guess the cheap option of increasing the buffer size hides the worst effects of breaking the stack.",
     "url": "https://github.com/lurcher/unixODBC/issues/239#issuecomment-5412604845"
    },
    {
     "type": "comment",
     "at": "2026-08-25T16:10:30Z",
     "actor": "lurcher",
     "association": "owner",
     "text": "Ok, I have added a check for writing past 12 bytes in sqlstate, its in a2acae7 At least this stops the disaster as soon as we can see it.",
     "url": "https://github.com/lurcher/unixODBC/issues/239#issuecomment-5413271552"
    }
   ],
   "reporter_comments": 2,
   "community_comments": 0,
   "last_activity": "2026-08-25T16:10:30Z",
   "pulse": true
  },
  {
   "project": "OpenLink Virtuoso",
   "repo": "openlink/virtuoso-opensource",
   "number": 1469,
   "url": "https://github.com/openlink/virtuoso-opensource/issues/1469",
   "title": "macOS ODBC driver (Homebrew 7.2.17) is built to iODBC's 4-byte SQLWCHAR, undocumented — process aborts on the first SQL error under unixODBC",
   "reported": "2026-08-25",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Dremio / Arrow Flight SQL ODBC",
   "repo": "dremio/warpdrive",
   "number": 16,
   "url": "https://github.com/dremio/warpdrive/issues/16",
   "title": "macOS Apple Silicon driver 0.9.7 is built to iODBC's 4-byte SQLWCHAR (undocumented): process aborts on the first SQL error under unixODBC; LogEnabled=true breaks SQLAllocHandle",
   "reported": "2026-08-25",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Firebird ODBC (OdbcFb)",
   "repo": "FirebirdSQL/firebird-odbc-driver",
   "number": 299,
   "url": "https://github.com/FirebirdSQL/firebird-odbc-driver/issues/299",
   "title": "Parameter arrays: fixed-length C types use BufferLength as the element stride, so every row receives element 0 (silent data corruption)",
   "reported": "2026-08-28",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Firebird ODBC (OdbcFb)",
   "repo": "FirebirdSQL/firebird-odbc-driver",
   "number": 300,
   "url": "https://github.com/FirebirdSQL/firebird-odbc-driver/issues/300",
   "title": "SQL_BIGINT parameter: once a NULL has been bound with a character C type (SQL_C_DEFAULT or SQL_C_CHAR), later SQL_C_SBIGINT rebinds on that parameter write NULL",
   "reported": "2026-08-28",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Firebird ODBC (OdbcFb)",
   "repo": "FirebirdSQL/firebird-odbc-driver",
   "number": 301,
   "url": "https://github.com/FirebirdSQL/firebird-odbc-driver/issues/301",
   "title": "SQLPrepare discards SQL_ATTR_ROWS_FETCHED_PTR and SQL_ATTR_ROW_STATUS_PTR set before it, so block cursors never learn how many rows a fetch returned",
   "reported": "2026-08-28",
   "reporter": "singhpratech",
   "what": "`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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "taos-odbc (TDengine)",
   "repo": "taosdata/taos-connector-odbc",
   "number": 63,
   "url": "https://github.com/taosdata/taos-connector-odbc/issues/63",
   "title": "SQLBindCol to SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP parameters, BOOL parameters other than SQL_C_SBIGINT->SQL_TINYINT, and any DECIMAL column are all \"not implemented yet\"",
   "reported": "2026-08-28",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Apache Doris",
   "repo": "apache/doris",
   "number": 67301,
   "url": "https://github.com/apache/doris/issues/67301",
   "title": "Prepared statements: a string parameter sent with MySQL type BLOB (what MySQL Connector/ODBC uses for every SQL_C_WCHAR parameter) is refused — 4.1.3 `Unsupported MySQL type: BLOB`, 2.1.0 NullPointerException",
   "reported": "2026-08-28",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "pull_request",
     "at": "2026-08-29T12:40:13Z",
     "actor": "1fanwang",
     "title": "[fix](fe) Accept BLOB prepared statement parameters",
     "url": "https://github.com/apache/doris/pull/67306",
     "state": "open"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": "2026-08-29T12:40:13Z",
   "pulse": true
  },
  {
   "project": "clickhouse-odbc",
   "repo": "ClickHouse/clickhouse-odbc",
   "number": 582,
   "url": "https://github.com/ClickHouse/clickhouse-odbc/issues/582",
   "title": "`SQL_NULL_DATA` is ignored when a value buffer is bound (an empty string is sent); a parameter array stops after set 1 (`SQLMoreResults` executes it but returns `SQL_NO_DATA`)",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "clickhouse-odbc",
   "repo": "ClickHouse/clickhouse-odbc",
   "number": 335,
   "url": "https://github.com/ClickHouse/clickhouse-odbc/issues/335#issuecomment-5464127498",
   "title": "Detect the number of affected rows by INSERT/UPDATE/DELETE.",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "comment on existing issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 3,
   "maintainer_events": [
    {
     "type": "labeled",
     "at": "2026-08-31T12:40:03Z",
     "actor": "slabko",
     "label": "bug"
    },
    {
     "type": "unlabeled",
     "at": "2026-08-31T12:40:10Z",
     "actor": "slabko",
     "label": "enhancement"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": "2026-08-31T12:40:10Z",
   "pulse": true
  },
  {
   "project": "OpenLink Virtuoso",
   "repo": "openlink/virtuoso-opensource",
   "number": 1470,
   "url": "https://github.com/openlink/virtuoso-opensource/issues/1470",
   "title": "virtodbc.so (Linux, unixODBC): SQL_C_WCHAR parameters and fetches use 4-byte wchar_t units, not the 2-byte SQLWCHAR the driver manager defines — \"hello\" stores as \"??\", \"héllo 🚀\" as \"0\", no diagnostic",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "comment",
     "at": "2026-08-31T23:50:49Z",
     "actor": "smalinin",
     "association": "collaborator",
     "text": "1. use UNICODE virtuoso ODBC driver 2. create DSN with option [code] DSN-less will NOT work properly with UTF16, that you need for unixODBC 3. Try connection with unixODBC unicode test tool `iusql` — it should work",
     "url": "https://github.com/openlink/virtuoso-opensource/issues/1470#issuecomment-5486412179"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": "2026-08-31T23:50:49Z",
   "pulse": true
  },
  {
   "project": "OpenLink Virtuoso",
   "repo": "openlink/virtuoso-opensource",
   "number": 1471,
   "url": "https://github.com/openlink/virtuoso-opensource/issues/1471",
   "title": "virtodbc.so: Charset=<any value but the exact literal UTF-8> aborts the process inside SQLDriverConnect (\"GPF: Dkbox.c:638 Double free\", SIGSEGV), including every charset Virtuoso itself lists; Charset=UTF-8 connects but returns wide columns doubly encoded",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "OpenLink Virtuoso",
   "repo": "openlink/virtuoso-opensource",
   "number": 1472,
   "url": "https://github.com/openlink/virtuoso-opensource/issues/1472",
   "title": "virtodbc.so: SQL_C_SBIGINT parameters store 0 and SQL_C_SBIGINT fetches return indicator 0 with the buffer untouched, silently; SQL_C_SLONG parameters are read as 8 bytes regardless of BufferLength",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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`.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "OpenLink Virtuoso",
   "repo": "openlink/virtuoso-opensource",
   "number": 1473,
   "url": "https://github.com/openlink/virtuoso-opensource/issues/1473",
   "title": "virtodbc.so: 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 with SQL_SUCCESS",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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`.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "MySQL Connector/ODBC",
   "repo": "mysql/mysql-connector-odbc",
   "number": 20,
   "url": "https://github.com/mysql/mysql-connector-odbc/issues/20",
   "title": "SQLDescribeCol reports COLUMN_SIZE=19 / DECIMAL_DIGITS=0 for DATETIME(6) (values are 26 chars) and SQLColumns reports COLUMN_SIZE NULL for date/datetime",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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).",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "MySQL Connector/ODBC",
   "repo": "mysql/mysql-connector-odbc",
   "number": 21,
   "url": "https://github.com/mysql/mysql-connector-odbc/issues/21",
   "title": "Client crashes with SIGFPE in get_column_size() (utility.cc) during SQLExecDirect of SHOW VARIABLES when the server's result metadata has a zero character-set length",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "Apache Ignite ODBC",
   "repo": "apache/ignite",
   "number": 13537,
   "url": "https://github.com/apache/ignite/issues/13537",
   "title": "ODBC: column-wise parameter array reads the NULL indicator of row 0 for every row — a NULL below row 0 stores an empty string (VARCHAR) or segfaults the client in SQLExecute (BINARY)",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "OpenSearch SQL ODBC",
   "repo": "opensearch-project/sql-odbc",
   "number": 101,
   "url": "https://github.com/opensearch-project/sql-odbc/issues/101",
   "title": "Any character value converted to SQL_C_TYPE_TIMESTAMP or SQL_C_TYPE_DATE comes back as today's date under SQL_SUCCESS (convert.c fills an unparsed SIMPLE_TIME from localtime)",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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`.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [
    "untriaged"
   ],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "labeled",
     "at": "2026-08-29T19:40:17Z",
     "actor": "github-actions[bot]",
     "label": "untriaged"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": "2026-08-29T19:40:17Z",
   "pulse": true
  },
  {
   "project": "OpenSearch SQL ODBC",
   "repo": "opensearch-project/sql-odbc",
   "number": 102,
   "url": "https://github.com/opensearch-project/sql-odbc/issues/102",
   "title": "SQLError/SQLErrorW returns the same connection error on every call and never SQL_NO_DATA, so unixODBC's SQLDriverConnect(W) spins forever on any failed connect (closed port, useSSL mismatch, bad auth=…)",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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`.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [
    "untriaged"
   ],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "labeled",
     "at": "2026-08-29T20:11:09Z",
     "actor": "github-actions[bot]",
     "label": "untriaged"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": "2026-08-29T20:11:09Z",
   "pulse": true
  },
  {
   "project": "QuestDB",
   "repo": "questdb/questdb",
   "number": 7566,
   "url": "https://github.com/questdb/questdb/issues/7566",
   "title": "pgwire: a BINARY column in a simple-query (Query message) result is sent with format code 1 (raw bytes); PostgreSQL always sends text there, so libpq/psycopg and psqlodbc truncate the value at its first 0x00",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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`.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "pull_request",
     "at": "2026-08-30T04:37:54Z",
     "actor": "spssspss0712",
     "title": "fix(pgwire): fix text format code for simple queries",
     "url": "https://github.com/questdb/questdb/pull/7569",
     "state": "open"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 1,
   "last_activity": "2026-08-30T04:37:54Z",
   "pulse": true
  },
  {
   "project": "QuestDB",
   "repo": "questdb/questdb",
   "number": 7567,
   "url": "https://github.com/questdb/questdb/issues/7567",
   "title": "pgwire: DEALLOCATE ALL fails with `Cannot invoke \"io.questdb.cutlass.pgwire.PGPipelineEntry.close()\" because \"pe\" is null` — even on a fresh connection with nothing prepared",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "commit",
     "at": "2026-08-30T03:11:00Z",
     "actor": "spssspss0712",
     "url": "https://github.com/questdb/questdb/commit/dbc2a62c793aacc6ba9cb8bedcb5d589e13e6712"
    },
    {
     "type": "pull_request",
     "at": "2026-08-30T03:13:48Z",
     "actor": "spssspss0712",
     "title": "fix(pgwire): avoid NullPointerException when releasing null entry to …",
     "url": "https://github.com/questdb/questdb/pull/7568",
     "state": "open"
    }
   ],
   "reporter_comments": 0,
   "community_comments": 1,
   "last_activity": "2026-08-30T03:13:48Z",
   "pulse": true
  },
  {
   "project": "CrateDB",
   "repo": "crate/crate",
   "number": 20085,
   "url": "https://github.com/crate/crate/issues/20085",
   "title": "pgwire: 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",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "fixed",
   "closed_at": "2026-08-31T08:57:20Z",
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "pull_request",
     "at": "2026-08-31T08:45:23Z",
     "actor": "mfussenegger",
     "title": "Fix pgwire command tags for multi statement execution",
     "url": "https://github.com/crate/crate/pull/20088",
     "state": "merged"
    },
    {
     "type": "commit",
     "at": "2026-08-31T08:51:42Z",
     "actor": "mfussenegger",
     "url": "https://github.com/crate/crate/commit/364db0da7572b4fafe522685bcc43c6e1804209e"
    },
    {
     "type": "commit",
     "at": "2026-08-31T08:55:48Z",
     "actor": "mfussenegger",
     "url": "https://github.com/crate/crate/commit/732f095569ed618b3326f65501b7677bb5888717"
    },
    {
     "type": "comment",
     "at": "2026-08-31T08:57:20Z",
     "actor": "mfussenegger",
     "association": "member",
     "text": "Thank you for the report. This will be fixed in 6.4.4 via https://github.com/crate/crate/pull/20088",
     "url": "https://github.com/crate/crate/issues/20085#issuecomment-5476086808"
    },
    {
     "type": "closed",
     "at": "2026-08-31T08:57:20Z",
     "actor": "mfussenegger",
     "reason": null,
     "commit": null
    },
    {
     "type": "commit",
     "at": "2026-08-31T09:36:41Z",
     "actor": "mfussenegger",
     "url": "https://github.com/crate/crate/commit/7b00c6adbf7c642f585ccfb79491ec89fbb7ac8f"
    },
    {
     "type": "commit",
     "at": "2026-08-31T09:49:59Z",
     "actor": "mergify[bot]",
     "url": "https://github.com/crate/crate/commit/fb0b41c123c755fa4a0b6d6d248ac67cf6e6dec1"
    },
    {
     "type": "pull_request",
     "at": "2026-08-31T09:50:16Z",
     "actor": "mergify[bot]",
     "title": "Fix pgwire command tags for multi statement execution (backport #20088)",
     "url": "https://github.com/crate/crate/pull/20091",
     "state": "merged"
    },
    {
     "type": "commit",
     "at": "2026-08-31T09:57:17Z",
     "actor": "mfussenegger",
     "url": "https://github.com/crate/crate/commit/5c99d680642a847620cbd1bc297567590aba03fd"
    },
    {
     "type": "commit",
     "at": "2026-08-31T10:14:52Z",
     "actor": "mergify[bot]",
     "url": "https://github.com/crate/crate/commit/cd8922a3f4939f4f9ab3ad9fe34633c246eaba3b"
    },
    {
     "type": "comment",
     "at": "2026-08-31T17:45:54Z",
     "actor": "mfussenegger",
     "association": "member",
     "text": "With the python script from your description I btw. got the following output with the fix included: [code] Note that I added a `refresh table` after the second insert to get the update rowcount 2 - otherwise it would be 0 as by default new records take a second to become visible without explicit refresh.",
     "url": "https://github.com/crate/crate/issues/20085#issuecomment-5482210527"
    }
   ],
   "reporter_comments": 2,
   "community_comments": 0,
   "last_activity": "2026-08-31T17:45:54Z",
   "pulse": true
  },
  {
   "project": "psqlodbc",
   "repo": "postgresql-interfaces/psqlodbc",
   "number": 207,
   "url": "https://github.com/postgresql-interfaces/psqlodbc/issues/207",
   "title": "SQLGetData/SQLBindCol narrow an out-of-range int8 to SQL_C_SLONG (and int4/int8 to SQL_C_SSHORT) silently: 9223372036854775807::bigint reads as -1 under SQL_SUCCESS where ODBC specifies 22003",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "`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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [],
   "reporter_comments": 0,
   "community_comments": 0,
   "last_activity": null,
   "pulse": false
  },
  {
   "project": "psqlodbc",
   "repo": "postgresql-interfaces/psqlodbc",
   "number": 208,
   "url": "https://github.com/postgresql-interfaces/psqlodbc/issues/208",
   "title": "With Protocol=7.4-0 (rollback on error: none), SQLFreeHandle of a prepared statement inside a transaction still sends \"SAVEPOINT _per_query_svp_;DEALLOCATE …;RELEASE _per_query_svp_\"; when the server rejects it the error is swallowed and SQLEndTran(SQL_COMMIT) returns SQL_SUCCESS although the server rolled the transaction back",
   "reported": "2026-08-29",
   "reporter": "singhpratech",
   "what": "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.",
   "kind": "issue",
   "state": "open",
   "closed_at": null,
   "labels": [],
   "reactions": 0,
   "maintainer_events": [
    {
     "type": "comment",
     "at": "2026-08-30T11:36:11Z",
     "actor": "davecramer",
     "association": "contributor",
     "text": "Thanks for the report. I do find it interesting that folks expect this to just work with non-postgres servers. That said I think we can fix it",
     "url": "https://github.com/postgresql-interfaces/psqlodbc/issues/208#issuecomment-5468439777"
    },
    {
     "type": "pull_request",
     "at": "2026-08-30T12:04:56Z",
     "actor": "davecramer",
     "title": "Don't savepoint-wrap internal queries at rollback level 0 (Protocol=7.4-0) (#208)",
     "url": "https://github.com/postgresql-interfaces/psqlodbc/pull/209",
     "state": "open"
    },
    {
     "type": "comment",
     "at": "2026-08-31T15:38:44Z",
     "actor": "davecramer",
     "association": "contributor",
     "text": "@singhpratech so PR #209 is an attempt to fix the problem, let me know if it works",
     "url": "https://github.com/postgresql-interfaces/psqlodbc/issues/208#issuecomment-5480687345"
    }
   ],
   "reporter_comments": 2,
   "community_comments": 0,
   "last_activity": "2026-08-31T15:38:44Z",
   "pulse": true
  }
 ]
}