feat!: adapt to core's catalog query types and sealed rows, and correct four info values

The follow-up the previous commit deferred, plus everything else core moved
since. Three breaking changes with no compiling intermediate state, so they land
together.

Catalog query types. The six catalog methods take a sealed query object instead
of five to eight positional arguments — `SQLForeignKeys` alone took six
`Option<&str>` in a row, where crossing a primary-key argument with its
foreign-key counterpart compiled without complaint. The query travels all the
way into `metadata.rs` rather than being unpacked at the trait boundary, which
would reintroduce that hazard one layer down. `TablesQuery::table_types()` is a
`&[String]` core has already split on commas and stripped the quotes from, so
`metadata::tables` loses its own parsing; a lone "%" still arrives, because the
`SQL_ALL_TABLE_TYPES` enumeration core answers itself additionally requires the
other three arguments to be empty strings, and is still read as no filter.

Sealed rows. Every catalog row type is `#[non_exhaustive]`, so the eight struct
literals become `Default` plus the consuming setter per column. A column this
driver does not populate is now unnamed rather than spelled `None`, which is the
point — it makes a column added to a spec result set a core-only change — so
each site says in a comment which columns it leaves NULL and why.

Ten new required capability hooks. Six are values this driver already stated and
that now move out of `sqlite_get_info` into the hook, because answering in both
places is the "declare it once" violation AGENTS.md describes: `driver_name`,
`driver_version`, `dbms_name`, `dbms_version`, `integrity` and `txn_capable`.
The snapshot pins all six regardless of which layer answers, which is what made
moving them safe. Two more were already pinned at core's default and are now
claims this driver makes on purpose: `accessible_procedures` "N" and
`txn_capable` SQL_TC_DML. `driver_name`/`driver_version` take no connection —
the Windows DM asks for driver identity before `SQLDriverConnectW` — while
`dbms_name`/`dbms_version` describe what was connected to and take one.

Two info values were wrong, and both are now live-probed rather than read off the
documentation. `SQL_QUOTED_IDENTIFIER_CASE` claimed SQL_IC_SENSITIVE, telling an
application that "T" and "t" are different tables; in SQLite double quotes are a
delimiter, not a case-sensitivity switch, so it is SQL_IC_MIXED, and the probe
asserts both halves of that — case-insensitive matching and mixed-case storage.
`SQL_SPECIAL_CHARACTERS` claimed "", which was core's old default rather than a
claim this driver ever made; SQLite parses `$` in an undelimited identifier, so
it is "$", probed over 31 candidates with the rejected ones asserted too. The
negative half is what stops it understating again, the same lesson
`alter_table_capabilities_are_each_live_probed` records.

SQLRowCount. Core now reads a zero-column statement reporting `Some(0)` as
SQL_NO_DATA, per SQLExecDirect's Comments, which surfaced that this driver
answered `Some(0)` for DDL — so every `CREATE TABLE` it ran returned SQL_NO_DATA
to the application, and 60 of the 66 initial test failures were that. `row_count`
now distinguishes "counted zero" from "no count applies". SQLite exposes no
predicate for this (`sqlite3_stmt_readonly` is false for DDL too), so
`is_searched_dml` decides from the leading keyword, past whitespace and both
comment forms, counting REPLACE and WITH alongside the obvious three. That also
removes a stale count: `sqlite3_changes()` reports the most recently completed
INSERT, UPDATE or DELETE, so a `CREATE TABLE` run after a three-row INSERT was
handed that 3 and reported it.

Two values changed underneath us, both core-owned and both describing core's
fetch path rather than SQLite, so the snapshot follows: `SQL_CURSOR_SENSITIVITY`
to SQL_UNSPECIFIED, and `SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2` to
SQL_CA2_READ_ONLY_CONCURRENCY.

Tests. The two `get_info_every_named_info_type_has_the_declared_shape_*` tests
asserted SQL_SUCCESS where core now documents that the shape probe's zero-length
buffer is total truncation; they assert "not SQL_ERROR", which is what their own
messages always claimed. `dbms_ver_is_well_formed` and `driver_ver_is_well_formed`
read through the hooks, the first via `test_connection` since it needs a data
source. `SQL_MULTIPLE_ACTIVE_TXN` has no `odbc_sys::InfoType` variant, so it is
pinned through the raw path — the snapshot iterates named types only.

Also fixes a pre-existing rustdoc failure that only surfaced once the crate
compiled again: a public doc comment linked to the `pub(crate)`
`SqliteConnection::interrupt`.

Verified against stackable-odbc-core dd25a22: cargo test 280 passing, clippy
clean, `pre-commit run --all-files` green across all 15 hooks, and the pyodbc
suite 23/23 through real unixODBC.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: maltesander

AGENTS.md

@@ -20,6 +20,7 @@ the 73 C ABI entry points — lives in
 | [Declaring capabilities](#declaring-capabilities) | Adding or changing any `SQLGetInfo` value |
 | [Transactions](#transactions) | Touching `SQLEndTran`, autocommit or cursor behaviour |
 | [Cancellation](#cancellation) | Touching `SQLCancel` or `SQL_ATTR_QUERY_TIMEOUT` |
+| [`row_count` has three answers](#row_count-has-three-answers-not-two) | Touching `SQLRowCount` or the execute path |
 | [Catalog functions](#catalog-functions) | Touching anything in `metadata.rs` |
 | [Architecture](#architecture-of-this-crate) | Understanding the module layout |
 | [Connection string keys](#connection-string-keys) | Adding or changing a parameter |
@@ -179,26 +180,35 @@ database file is `08001`. Failures after that point are `08S01`.
 
 ### Declaring capabilities
 
-`Backend` has around two dozen **required** methods that state what SQLite can
+`Backend` has around thirty **required** methods that state what SQLite can
 do — `alter_table_support`, `outer_join_capabilities`, `subqueries`,
 `sql_conformance`, `supports_catalogs`, `identifier_case`,
-`txn_isolation_options`, `table_types` and the rest. They are required, with no
-default, deliberately: a defaulted capability is a claim no backend ever made,
-and every one of them was a bug here before core made it a compile error.
-`table_types` is required for the same reason and one of its own: an empty
-table-type list is an *answer* ("this data source has no table types"), not
-"unknown", and unlike catalogs and schemas there is no `supports_*` method for
-core to derive it from.
+`quoted_identifier_case`, `txn_capable`, `txn_isolation_options`, `integrity`,
+`multiple_active_txn`, `special_characters`, `accessible_procedures`,
+`dbms_name`, `dbms_version`, `table_types` and the rest. They are required,
+with no default, deliberately: a defaulted capability is a claim no backend
+ever made, and every one of them was a bug here before core made it a compile
+error. `table_types` is required for the same reason and one of its own: an
+empty table-type list is an *answer* ("this data source has no table types"),
+not "unknown", and unlike catalogs and schemas there is no `supports_*` method
+for core to derive it from. `special_characters` is required on that same
+principle — `""` asserts that nothing beyond the alphanumerics and underscore
+is legal unquoted, which is a claim, not an absence, and inheriting it as a
+default is how this driver came to under-report `$`.
 
 They all take `&Self::Connection`, because `SQLGetInfo` is a per-connection
 call and a data source's capabilities can differ by server. Every one this
 driver declares is a property of the SQLite `rusqlite` links, not of the file
 opened, so each ignores the argument — but the answer must still be read
 through a connection, and the tests do that via `info::tests::test_connection`
 rather than calling the hook as a free function. `cursor_commit_behavior`,
-`cursor_rollback_behavior` and `catalog_result_column_widths` are the
-exceptions and take none: `SQLGetInfo` must answer the first two before a
-connection exists.
+`cursor_rollback_behavior`, `catalog_result_column_widths`, `driver_name` and
+`driver_version` are the exceptions and take none: `SQLGetInfo` must answer the
+first three before a connection exists, and the Windows Driver Manager asks for
+driver identity before `SQLDriverConnectW`. Note the split within the identity
+group — `driver_name`/`driver_version` describe the driver and take no
+connection, while `dbms_name`/`dbms_version` describe what was connected to and
+take one.
 
 The same split runs through `get_info`. `sqlite_get_info` takes
 `Option<&SqliteConnection>` — `None` on the pre-connect path — and hands it to
@@ -366,14 +376,77 @@ This is load-bearing well beyond memory use. It is why the cursor-behaviour
 hooks report `Preserve`, why `SQLEndTran` cannot disturb a cursor, and why
 concurrency is a non-issue. Changing it is not a local optimisation.
 
+### `row_count` has three answers, not two
+
+`StatementBackend::row_count` returns `Option<i64>`, and core reads all three
+possibilities differently:
+
+| Answer | Means | Here |
+|--------|-------|------|
+| `Some(n)` | the backend counted | a searched INSERT / UPDATE / DELETE, or a materialised result set |
+| `Some(-1)` | `SQL_NO_TOTAL`, cannot determine | a count exceeding `i64`; unreachable in practice |
+| `None` | not applicable to this statement | DDL, transaction control, `PRAGMA`, an unexecuted prepared statement |
+
+The distinction between the last two is not cosmetic. Core turns a statement
+with **zero columns** reporting **`Some(0)`** into `SQL_NO_DATA`, which is
+`SQLExecDirect`'s documented behaviour for "a searched update, insert, or
+delete statement that doesn't affect any rows". Answering `Some(0)` for DDL
+therefore made every `CREATE TABLE` return `SQL_NO_DATA`.
+
+SQLite offers no predicate for "is this DML" — `sqlite3_stmt_readonly` is false
+for DDL too — so `execute::is_searched_dml` decides it from the statement's
+leading keyword, past whitespace and both comment forms. `REPLACE` and `WITH`
+count alongside the obvious three: the first is an `INSERT OR REPLACE` alias,
+and the second fronts a CTE, which is only ever consulted for a zero-column
+statement, so a `WITH` that declared no columns cannot be a `WITH ... SELECT`.
+Being wrong is not symmetric, so an unrecognised keyword answers "no count":
+withholding a count leaves `SQLRowCount` at -1, while inventing one fabricates
+`SQL_NO_DATA`.
+
+Do **not** replace this with the number `rusqlite`'s `execute()` returns.
+`sqlite3_changes()` reports the rows touched by the *most recently completed*
+INSERT, UPDATE or DELETE, so a `CREATE TABLE` run after a three-row `INSERT` is
+handed that `3`. `ddl_after_dml_does_not_inherit_the_dml_row_count` pins it.
+
 ### Catalog functions
 
-The six catalog methods return **typed row vectors** — `Vec<TableRow>`,
+The six catalog methods take a **typed query object** — `&TablesQuery`,
+`&ColumnsQuery`, `&PrimaryKeysQuery`, `&ForeignKeysQuery`, `&StatisticsQuery`,
+`&SpecialColumnsQuery` — and return **typed row vectors** — `Vec<TableRow>`,
 `Vec<ColumnRow>`, `Vec<PrimaryKeyRow>`, `Vec<ForeignKeyRow>`,
 `Vec<StatisticsRow>`, `Vec<SpecialColumnRow>` — not a `Self::Statement`. Core
 converts each row to the spec's column layout, sorts the set into the order
-that function's spec page mandates, and serves it. Three consequences for
-anything changed in `metadata.rs`:
+that function's spec page mandates, and serves it.
+
+Both sides are core's types and both are sealed, which is what a change in
+`metadata.rs` has to work with:
+
+- **Neither has a struct expression here.** Every row type is
+  `#[non_exhaustive]`, so a row is built from `Default` and the consuming
+  setter per column: `TableRow::default().name(n).table_type(t)`. Each setter
+  takes `impl Into<T>`, so an `Option<String>` column accepts a bare `String`.
+  A column a driver does not populate is simply not named — which is the point,
+  since it makes a column added to a spec result set a core-only change instead
+  of a break in every driver. The query types are sealed the same way, with
+  crate-private fields, an accessor and a `with_*` setter per field, and a
+  `new()` for the arguments that have no honest default (`StatisticsQuery`'s
+  `unique_only`, `SpecialColumnsQuery`'s `identifier_type`/`scope`/`nullable`).
+- **Read the filters off the query, do not destructure it.** The run of
+  same-typed `Option<&str>` arguments these hooks used to take is exactly what
+  the query types exist to remove: `SQLForeignKeys` took six in a row, where
+  swapping a primary-key argument for its foreign-key counterpart compiled
+  without complaint. Unpacking a query back into positional arguments at the
+  trait boundary reintroduces that hazard one layer down, so the query travels
+  all the way into `metadata.rs`.
+- **`TablesQuery::table_types()` is already parsed.** Core splits `TableType`
+  on commas and strips the optional single quotes — it is a value list, not a
+  pattern, and `SQL_ATTR_METADATA_ID` never applies to it — so a backend gets a
+  `&[String]` and never parses it. Empty means no filter. A lone `"%"` does
+  still arrive, because the `SQL_ALL_TABLE_TYPES` enumeration core answers
+  itself additionally requires the other three arguments to be empty strings;
+  `metadata::tables` reads that as no filter.
+
+Three further consequences for anything changed in `metadata.rs`:
 
 - **Do not sort, and do not add an `ORDER BY` for ODBC's sake.** Core sorts,
   stably, on the spec's keys. A second ordering in the backend is one more

CHANGELOG.md

@@ -70,6 +70,35 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- `SQL_QUOTED_IDENTIFIER_CASE` reports `SQL_IC_MIXED` instead of
+  `SQL_IC_SENSITIVE`. In SQLite, double quotes are a *delimiter* — they let a
+  keyword or a name with punctuation be used as an identifier — and do not
+  switch on case-sensitive matching the way they do in a SQL-92 conformant
+  DBMS: a table created as `"MixedCase"` is found by `"mixedcase"`, and the
+  catalog stores the name with the case it was written in. The old value told
+  an application that `"T"` and `"t"` were different tables. Both halves of the
+  new claim — case-insensitive matching and mixed-case storage — are probed
+  against the bundled library rather than read off the documentation.
+
+- `SQL_SPECIAL_CHARACTERS` reports `$` instead of the empty string. SQLite's
+  tokenizer treats `$` as an identifier character, so `a$b` parses undelimited
+  and round-trips through `sqlite_master` unchanged. An application reads this
+  info type to decide when it must quote, and the empty string had it quoting a
+  name that needs no quoting. The empty string was `stackable-odbc-core`'s
+  default rather than a claim this driver ever made; it is now a per-connection
+  `Backend` hook, and every candidate character is executed against the bundled
+  library, the rejected ones included.
+
+- `SQL_CURSOR_SENSITIVITY` reports `SQL_UNSPECIFIED` instead of
+  `SQL_INSENSITIVE`, and `SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2` reports
+  `SQL_CA2_READ_ONLY_CONCURRENCY` instead of `0`. Both describe
+  `stackable-odbc-core`'s own fetch path rather than SQLite, and both now come
+  from core: insensitivity would be a promise that no other cursor's changes
+  become visible, which core does not make about rows it has not read yet,
+  while `0` for the second denied the one concurrency
+  `SQLSetStmtAttr(SQL_ATTR_CONCURRENCY)` actually accepts. This follows a
+  `stackable-odbc-core` change.
+
 - `SQLDescribeCol` and `SQLColAttribute` report each result column's real
   nullability instead of claiming every column is nullable. A column declared
   `NOT NULL` is now `SQL_NO_NULLS`, a plain table column `SQL_NULLABLE`, and a
@@ -224,6 +253,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- `SQLRowCount` reported `0` after a `CREATE TABLE`, `DROP TABLE`, `ALTER
+  TABLE`, `BEGIN`, `COMMIT`, `PRAGMA` or `VACUUM`, where the spec's
+  affected-row count does not apply at all. The three answers are now distinct:
+  a count for a searched INSERT / UPDATE / DELETE, the materialised size of a
+  result set, and *no count* for everything else. This matters beyond
+  tidiness — `stackable-odbc-core` reads a zero-column statement reporting a
+  counted zero as `SQL_NO_DATA`, per `SQLExecDirect`'s Comments, so every DDL
+  statement this driver ran returned `SQL_NO_DATA` to the application instead
+  of `SQL_SUCCESS`. A searched DELETE that matches nothing still reports `0`,
+  which is the case the spec reserves `SQL_NO_DATA` for.
+
+  The same fix removes a stale count: `sqlite3_changes()` reports the rows
+  touched by the *most recently completed* INSERT, UPDATE or DELETE, so a
+  `CREATE TABLE` run straight after a three-row `INSERT` was handed that `3`
+  and reported it.
+
 - `SQLForeignKeys` reported `PKCOLUMN_NAME` as NULL for a foreign key declared
   without an explicit column list (`REFERENCES parent`), a column the spec
   marks "not NULL". SQLite defines the implicit target as the parent table's