fix!: enforce the backend/SQLGetInfo split with a test

Every item in the last three rounds was found by reading default_get_info
by hand and asking whether core had any business knowing the value. That
does not scale and it kept missing things. Replace the audit with a test.

default_get_info_answers_are_backend_derived_or_declared_core_facts
evaluates default_get_info for two mock backends that share no capability
declaration, and asks one question of every info type: does the answer
move when the backend does? An info type answering identically for both
is one core decided, and must appear in the test's CORE_FACTS list with
the reason core is entitled to decide it -- a fact about core's own
implementation (its fetch really is forward-only, the Backend trait
really is synchronous), a limit where the spec defines 0 as "no limit or
unknown", or driver identity with no per-backend answer. Hard-coding a
claim about the data source now fails a test that names the info type.

A second test asserts the two mocks differ in every hook, since the
classification is only as strong as that.

Running it surfaced what the hand audit had left:

- SQL_SUBQUERIES, SQL_COLUMN_ALIAS and SQL_CONCAT_NULL_BEHAVIOR are the
  other half of the conformance contradiction fixed in 5f797be. The spec
  names all three as values a SQL-92 Entry level-conformant driver
  returns and core hard-coded exactly those, so a backend declaring no
  conformance level was still reported as supporting correlated
  subqueries, quantified predicates and column aliases. SQL_SUBQUERIES is
  the one applications act on: claiming SQL_SQ_CORRELATED_SUBQUERIES for
  a source without them is how a BI tool pushes down SQL the server
  rejects. SQL_CONCAT_NULL_BEHAVIOR was also a bare 0 literal for a
  spec-named constant; SQL_CB_NULL and SQL_CB_NON_NULL now exist.

- SQL_UNION, SQL_CONVERT_FUNCTIONS, SQL_ORDER_BY_COLUMNS_IN_SELECT,
  SQL_ACCESSIBLE_TABLES, SQL_DATA_SOURCE_READ_ONLY and
  SQL_SEARCH_PATTERN_ESCAPE were all statements about the data source
  core had no way to know. SQL_ACCESSIBLE_TABLES was the sharpest: "Y"
  guarantees the connected user has SELECT on every table SQLTables
  returns, which depends on the principal, not the driver.

- SQL_IDENTIFIER_QUOTE_CHAR is now derived from
  EscapeDialect::identifier_quotes instead of hard-coded to `"`. The
  escape translator already consulted the dialect, so a backend quoting
  with a backtick had core telling applications something the translator
  contradicted. No new hook -- the fact was already declared, which is
  the better fix and is now written into AGENTS.md as a rule.

BREAKING CHANGE: Backend gains required methods subqueries, column_alias,
concat_null_behavior, union_support, convert_functions,
order_by_columns_in_select, accessible_tables, data_source_read_only and
search_pattern_escape.

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

Author: maltesander

AGENTS.md

@@ -221,6 +221,15 @@ These deliberately are not:
 | `sql_conformance` | `SQL_SQL_CONFORMANCE` (`SQL_SC_*`) |
 | `timedate_add_intervals` | `SQL_TIMEDATE_ADD_INTERVALS` (`SQL_FN_TSI_*`) |
 | `timedate_diff_intervals` | `SQL_TIMEDATE_DIFF_INTERVALS` (`SQL_FN_TSI_*`) |
+| `subqueries` | `SQL_SUBQUERIES` (`SQL_SQ_*`) |
+| `column_alias` | `SQL_COLUMN_ALIAS` |
+| `concat_null_behavior` | `SQL_CONCAT_NULL_BEHAVIOR` (`0` = `SQL_CB_NULL`) |
+| `union_support` | `SQL_UNION` (`SQL_U_*`) |
+| `convert_functions` | `SQL_CONVERT_FUNCTIONS` (`SQL_FN_CVT_*`) |
+| `order_by_columns_in_select` | `SQL_ORDER_BY_COLUMNS_IN_SELECT` |
+| `accessible_tables` | `SQL_ACCESSIBLE_TABLES` |
+| `data_source_read_only` | `SQL_DATA_SOURCE_READ_ONLY` |
+| `search_pattern_escape` | `SQL_SEARCH_PATTERN_ESCAPE` |
 
 Each states a **capability**, where any default is a claim the backend author
 never made. `0` understates ("this data source cannot do this at all") and
@@ -251,12 +260,37 @@ Two corollaries worth checking when adding an info type:
   `""`, which is the right *shape* but is not in any Y/N value list. Such a
   type needs either a shared `"N"` arm in `default_get_info` or a hook.
 - **Watch for info types that constrain each other.** `SQL_SQL_CONFORMANCE`
-  fixes the value of `SQL_GROUP_BY`, `SQL_CORRELATION_NAME` and
-  `SQL_NON_NULLABLE_COLUMNS` (the spec names what an entry-level driver
-  returns for each); `SQL_TIMEDATE_FUNCTIONS` claiming
+  fixes the value of `SQL_GROUP_BY`, `SQL_CORRELATION_NAME`,
+  `SQL_NON_NULLABLE_COLUMNS`, `SQL_CONCAT_NULL_BEHAVIOR`, `SQL_SUBQUERIES`
+  and `SQL_COLUMN_ALIAS` — the spec names what an entry-level driver returns
+  for each of those six. `SQL_TIMEDATE_FUNCTIONS` claiming
   `SQL_FN_TD_TIMESTAMPADD` obliges `SQL_TIMEDATE_ADD_INTERVALS` to be
-  non-zero. Core supplying one side of such a pair while the backend supplies
-  the other is how it ends up contradicting itself.
+  non-zero. `SQL_CATALOG_NAME` drives the whole catalog group. Core supplying
+  one side of such a pair while the backend supplies the other is how it ends
+  up contradicting itself.
+- **Prefer deriving over adding a hook when the fact is already declared.**
+  `SQL_IDENTIFIER_QUOTE_CHAR` comes from `EscapeDialect::identifier_quotes`
+  and `SQL_CURSOR_COMMIT_BEHAVIOR` from `Backend::cursor_commit_behavior`,
+  because a second way to state the same fact is a second way to state it
+  *differently*. Check whether an existing hook already answers the question
+  before adding one.
+
+#### The rule is enforced by a test, not by review
+
+`default_get_info_answers_are_backend_derived_or_declared_core_facts`
+(`src/backend.rs`) asks one question of every info type: **does the answer
+move when the backend does?** It evaluates `default_get_info` for two mock
+backends that share no capability declaration. An info type answering
+identically for both is one core decided, and must appear in that test's
+`CORE_FACTS` list together with the reason core is entitled to decide it —
+a fact about core's own implementation (its fetch really is forward-only, its
+`Backend` trait really is synchronous), a limit where the spec defines `0` as
+"no limit or unknown", or driver-level identity with no per-backend answer.
+
+So adding a hard-coded claim to `default_get_info` fails a test that names the
+info type. If you find yourself adding an entry to `CORE_FACTS`, the reason
+string is the test: if you cannot write one that is about *core* rather than
+about the data source, the value belongs on a `Backend` method.
 
 `supports_catalogs` and `supports_schemas` between them drive seven info types
 (`SQL_CATALOG_NAME`, `SQL_CATALOG_TERM`, `SQL_CATALOG_NAME_SEPARATOR`,

CHANGELOG.md

@@ -35,6 +35,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   `/usr/include/sql.h` and `sqlext.h` by
   `info_type_value_constants_match_sql_headers`. These are values where a typo
   cannot look empty, because zero is itself a valid claim for several of them.
+- A test that enforces the backend/`SQLGetInfo` split instead of leaving it to
+  review. `default_get_info_answers_are_backend_derived_or_declared_core_facts`
+  evaluates `default_get_info` for two mock backends sharing no capability
+  declaration; any info type answering identically for both is one core
+  decided, and must be listed with the reason core is entitled to decide it —
+  a fact about core's own implementation, a limit where the spec defines `0`
+  as "no limit or unknown", or driver identity. Hard-coding a claim about the
+  data source now fails a test naming the info type. Every item fixed in this
+  release was found by hand; this is what stops the next one needing that.
 - `EscapeDialect::rewrite_scalar_fn`, which receives a whole
   `{fn NAME(args)}` escape and returns the replacement text.
   `remap_scalar_fn` only swaps the identifier in front of the parentheses and
@@ -96,7 +105,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   `outer_join_capabilities`, `default_txn_isolation`,
   `txn_isolation_options`, `group_by`, `null_collation`, `correlation_name`,
   `non_nullable_columns`, `expressions_in_order_by`, `sql_conformance`,
-  `timedate_add_intervals` and `timedate_diff_intervals`.
+  `timedate_add_intervals`, `timedate_diff_intervals`, `subqueries`,
+  `column_alias`, `concat_null_behavior`, `union_support`,
+  `convert_functions`, `order_by_columns_in_select`, `accessible_tables`,
+  `data_source_read_only` and `search_pattern_escape`.
   They are required rather than defaulted on purpose:
   each states a *capability*, where a defaulted value is a claim the backend
   author never made and is unlikely to notice. A defaulted `0` understates and
@@ -151,6 +163,30 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   `SQL_CORRELATION_NAME`, `SQL_NON_NULLABLE_COLUMNS` and `SQL_GROUP_BY` values
   the spec says an entry-level driver never returns, so every backend built on
   core inherited a contradiction it could not see.
+- `SQL_SUBQUERIES`, `SQL_COLUMN_ALIAS` and `SQL_CONCAT_NULL_BEHAVIOR` come
+  from the backend too — the other half of that same contradiction. The spec
+  names all three as values a SQL-92 Entry level-conformant driver returns,
+  and core hard-coded exactly those, so a backend declaring *no* conformance
+  level was still reported as supporting correlated subqueries, quantified
+  predicates and column aliases. `SQL_SUBQUERIES` is the one an application
+  acts on: claiming `SQL_SQ_CORRELATED_SUBQUERIES` for a source without them
+  is how a BI tool comes to push down SQL the server rejects.
+  `SQL_CONCAT_NULL_BEHAVIOR` was additionally a bare `0` literal for a
+  spec-named constant; `SQL_CB_NULL` and `SQL_CB_NON_NULL` now exist.
+- `SQL_UNION`, `SQL_CONVERT_FUNCTIONS`, `SQL_ORDER_BY_COLUMNS_IN_SELECT`,
+  `SQL_ACCESSIBLE_TABLES` and `SQL_DATA_SOURCE_READ_ONLY` come from the
+  backend. Each was a statement about the data source that core had no way to
+  know. `SQL_ACCESSIBLE_TABLES` was the sharpest: `"Y"` guarantees the
+  connected user has `SELECT` on every table `SQLTables` returns, which
+  depends on the principal, not the driver.
+- `SQL_IDENTIFIER_QUOTE_CHAR` is derived from
+  `EscapeDialect::identifier_quotes` rather than hard-coded to `"`. The escape
+  translator already consulted the dialect, so a backend quoting identifiers
+  with a backtick or brackets had core telling applications something the
+  translator contradicted. No new hook: the fact was already declared.
+- `SQL_SEARCH_PATTERN_ESCAPE` comes from the backend. It describes what
+  escapes `%` and `_` in catalog-function pattern arguments, which the backend
+  interprets.
 - `SQL_EXPRESSIONS_IN_ORDERBY` is stated by the backend. It previously fell to
   `""`, which reads as "no" to a tool deciding whether to push an expression
   into `ORDER BY`.