rails-ai-context 5.35.2 → 5.36.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 40f690d7055b2ed848a3e2c381b9735a04a1e36daaf17b9b3be6ef8fb123b4e7
-  data.tar.gz: ef4a68d5e3cfaefa285f78f8292059fef488788c5368d6cf110dae1bfe6a0947
+  metadata.gz: 8ea836548c12d9e6a022ca0e9cb78f471c2144d5b16197ab9493808209c12f74
+  data.tar.gz: 1037665358df3ef107d83530dcec2371728b76df61852c51387b2797eb5bac51
 SHA512:
-  metadata.gz: c4fd6c004371524c34c681922c2d7b8a2f0e5de79e93071a6a2cc34a93d54e70ce1c3565333109c4975cdb6763ea8f1db5adaba9dd8a39444a87e6329cb55367
-  data.tar.gz: 71d3fff40bd09fc9f92955c8f816fd455bf4cf3c3c36ea46eda3c4296bafa5bd3abc31290e717de53d11062b2fb96355bbb961267be18e121d7261c20ad7c59c
+  metadata.gz: 007d9bbd31542ad5caa6847ce83443fa3d793483cbb93aefcd37dc03c4f4cbf536e51dfd4735ddcf27e0f6dda46b052a95f7f6317d2685f2b2cb8769da349819
+  data.tar.gz: a4815b990a54d309fe3b5a4ce97ab8b7fca7a50841a70825d3aa02378915fe77f0f5465259e3484efb2a8268e959f4877bde376a4617ee461e36e94292eb4301

data/CHANGELOG.md

@@ -5,6 +5,182 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [5.36.0] - 2026-10-14
+
+### Security
+
+- **On PostgreSQL a name on the read-only VOLATILE list vouches for the server's
+  own function and an extension's C function alone.** The list trusted a name in
+  any schema, so a VOLATILE function the app defined under one of those names
+  ran. While the database holds a VOLATILE function of a listed name in another
+  language outside `pg_catalog`, every call of the name is now refused, and the
+  refusal says so. 5.35.2 and earlier versions had the gap.
+- **On PostgreSQL 18 a set operation over a secret column is refused, as it is
+  on older servers.** PostgreSQL 18 plans a set operation over the tables
+  themselves, and the plan check that refuses a secret column passed through a
+  set operation did not read that shape. A set operation now counts every column
+  its inputs hand up as a use of that column. 5.35.2 and earlier versions had
+  the gap on PostgreSQL 18.
+
+### Changed
+
+- **On SQLite a call of `changes()`, `total_changes()` or
+  `last_insert_rowid()` is refused also where the app has a table of the same
+  name.** The counter answers for the connection that runs the statement,
+  which is `rails_query`'s own. 5.35.1 and 5.35.2 ran such a call when a table
+  carried the counter's name. Read the counter on the app's own connection, in
+  `bin/rails runner` or the console.
+- **The packaged gem holds only what a user of the gem runs or reads.** That is
+  `lib/`, `exe/`, `app/`, `config/`, the README, the changelog, the license,
+  `SECURITY.md`, the user docs in `docs/`, and the files those docs link to
+  (`CONTRIBUTING.md` and three ADRs), so every link works in the unpacked gem.
+  5.35.2 also packed the files that serve the repository alone: `AGENTS.md`,
+  `CLAUDE.md`, `CONTEXT.md`, `CODE_OF_CONDUCT.md`, `docs/RELEASING.md`, the
+  other ADRs, `docs/agents/`, the docs site config, `.rspec`, `.rubocop.yml`,
+  `.ruby-version`, `Rakefile` and `server.json`. A tool that indexes an app's
+  bundle could read the two assistant files as instructions about the app.
+
+### Fixed
+
+- **On PostgreSQL a read with `TABLESAMPLE` runs.** The name of the sampling
+  method (`BERNOULLI`, `SYSTEM`) was read as a call of a VOLATILE function, and
+  the statement was refused. The statement never calls it, so it is no longer
+  read as a call. A VOLATILE function called anywhere in the statement, one
+  named like a sampling method included, is still refused. 5.35.2 refused the
+  read.
+- **On PostgreSQL an `EXISTS` inside an `EXISTS` over a table with a secret
+  column runs.** The plan puts a Result node over the inner scan, and the plan
+  check counted every column of that scan as passed through, so the statement
+  was refused with a sentence saying it passed the secret column on. A Result
+  node is now read like a join: a column counts only where the Result names
+  it. A plain read of a few columns under a condition that holds no column
+  (`WHERE EXISTS (...)`) runs for the same reason. 5.35.2 refused them.
+- **On PostgreSQL `EXPLAIN (GENERIC_PLAN)` answers the plan.** The plan check
+  planned the statement under it without the option, so a statement with `$1` in
+  it answered an SQL error. It is now planned with the option, read as the
+  server reads it: its last value counts, quoted or not. A server older than
+  PostgreSQL 16 has no such option and still answers its error. 5.35.2 answered
+  the error.
+- **On PostgreSQL the `pg_sequences` view can be read.** It reads each
+  sequence's value through `pg_sequence_last_value`, a VOLATILE function that
+  writes nothing, and the statement was refused. The function now joins the
+  list of read-only VOLATILE functions. `nextval`, `setval`, `currval` and
+  `lastval` are still refused. 5.35.2 refused the view.
+- **A query leaves a transaction the app opened with a raw `BEGIN` open, with
+  its writes.** Active Record does not count such a transaction, so on
+  PostgreSQL the query sent its own `BEGIN` and then `ROLLBACK`, which ended
+  the app's transaction and threw its writes away; the answer also missed the
+  rows the transaction had written. PostgreSQL now reads the server's own
+  transaction status and guards inside a savepoint there, under the same
+  read-only transaction and statement timeout. On MySQL and MariaDB the answer
+  is the refusal an open transaction gets ("MySQL cannot make a transaction
+  that is already open read-only"), where 5.35.2 answered the server's error
+  1568, and no `BEGIN`, which would commit the app's transaction, is sent. On
+  a SQLite file the statement runs on the app's own connection and reads the
+  transaction's rows, where 5.35.2 answered from the file without them.
+  5.35.2 and every earlier version ended the transaction on PostgreSQL.
+- **On PostgreSQL a statement another session cancels is answered as the SQL
+  error it is.** A `pg_cancel_backend` from another session raises the same
+  error class as the statement timeout, and 5.35.2 answered "Query exceeded <N>
+  second timeout". The server's message tells the two apart, so a cancel now
+  answers `SQL error: PG::QueryCanceled: ERROR:  canceling statement due to user
+  request`. A real timeout keeps its sentence. A server that writes its messages
+  in another language still answers a cancel as the timeout.
+- **A query that reads a setting `rails_query` sets for each statement says so,
+  and gives the session's own value.** `SHOW statement_timeout` answered the
+  bound the tool set for the statement (`2s`) with nothing to say it was not the
+  session's (`50s`), and so did `transaction_read_only` on PostgreSQL, and the
+  statement limit (`max_execution_time` or `max_statement_time`) and
+  `lock_wait_timeout` on MySQL and MariaDB, by `@@` (the name backquoted or
+  not), by `SHOW VARIABLES` or by MariaDB's
+  `information_schema.SESSION_VARIABLES`. The answer now ends with a note, for
+  example "statement_timeout here is the value rails_query sets for each
+  statement it runs. The session's own: statement_timeout 50s." A name used as
+  an alias or a column, one in a string or a comment, and a global value on
+  MySQL and MariaDB get no note. 5.35.2 and earlier gave no note.
+- **On PostgreSQL 13 and 14 a temporary table runs, with its secret column
+  filtered.** Before PostgreSQL 15 a plan names the session's temporary schema
+  by its number (`pg_temp_3`), where the column reads name it `pg_temp`, so
+  5.35.2 refused every statement over a temporary table there as one whose
+  columns could not be read. A whole row of a temporary table that holds a
+  secret column stays refused.
+- **On SQLite a column whose own name starts with `pragma_` runs.** A
+  `pragma_*` name is now refused where SQLite reads it as the pragma function:
+  called, or where a table stands (after `FROM`, `JOIN` or `IN`, after a comma
+  of a `FROM` list, inside a parenthesis that opens one, or after a schema and a
+  dot there), bare, quoted or as a string. Anywhere else it is a column's or an
+  alias's name, and the statement runs. 5.35.1 and 5.35.2 refused such a name
+  wherever it stood, so `SELECT id FROM t WHERE pragma_flag = 1` was refused.
+- **On SQLite a secret column name covers only the columns SQLite reads it as.**
+  SQLite folds ASCII letters alone, so `"é"` and `"É"` are two columns, and the
+  secret column rule now compares names that way there. With `"É"` in
+  `query_redacted_columns`, `SELECT "é" FROM t` runs and `SELECT *` filters `É`
+  alone; every earlier version refused `é` too and filtered both. A name is
+  still read with every letter folded for what it means, so a column that folds
+  to a built-in name or one the heuristic flags stays secret, and so does one a
+  configured name folds to when no column spells that name as SQLite folds it.
+  PostgreSQL, MySQL and MariaDB fold every letter as before.
+- **On SQLite a statement that names a view over a pragma function or a
+  counter that tells of the connection is refused, by the view and the
+  function.** The view's definition runs on `rails_query`'s own connection, so
+  `CREATE VIEW v AS SELECT name FROM pragma_database_list` answered without
+  the app's attached databases, and a view calling `changes()` answered for the
+  wrong connection, both as a success. 5.35.1 and 5.35.2 refused the function
+  written in the statement alone. A view over a pragma function that describes
+  the schema or the database file, such as `pragma_table_info`, runs.
+- **Every preset names each database's adapter and lists the databases.** On
+  `preset: standard`, which runs no `multi_database` introspector, the static
+  tier called the primary's adapter `unknown` in `rails_onboard` and in the
+  generated files, named no adapter beside a second database, and left the `-
+  Databases:` line out of CLAUDE.md and `.claude/rules/rails-context.md`. The
+  context now carries the app databases list on every preset, and where the
+  `multi_database` introspector failed, so these answer what `preset: full`
+  answers. 5.35.2 and earlier versions had the gap.
+- **A model whose class body raises is named with what it raised.** Ruby
+  registers a class before its body runs, so a model file that raised partway
+  down its class was listed as `[VERIFIED]` with only what ran before the
+  raise, and with no word that loading it failed. It is now named with the
+  error, as a file that raises before its class opens has been since 5.35.2.
+  5.35.2 and earlier versions listed it.
+- **A booted model keeps its STI hierarchy while nothing has queried its
+  database.** A model whose table is in a second database, and so not in
+  `db/schema.rb`, lost its STI parent, children and type column until a first
+  query connected that database. The table is now read as not known to lack the
+  type column, as the static tier reads it, and a model with no STI parent or
+  child still answers no STI. An abstract base, such as the class a second
+  database connects through, is no STI parent. 5.35.2 and earlier versions had
+  the gap.
+- **The static mailer list adds the actions a mailer inherits from the app's own
+  mailers.** A `ShopMailer < BaseMailer` listed only the actions in its own
+  file, where Rails delivers the parent's public methods too and the booted tier
+  lists them. Each name now takes the visibility the nearest class gives it, so
+  a method the child makes private, under `private` or with `private :name`,
+  stays out. The methods of `ApplicationMailer` itself stay out too, as the
+  booted tier leaves them out, and on both tiers a mailer with no action of its
+  own names where they come from only for a parent past the app's own mailers,
+  such as `Devise::Mailer`, and none past `ApplicationMailer`. 5.35.2 and
+  earlier versions had the gap.
+- **`rails_get_schema` says when two databases share `db/schema.rb`.** Rails
+  dumps both the first database and the one named `primary` to that file, so it
+  holds whichever was dumped last. A table of the other database was called
+  missing from the connected one, with advice to run `rails db:migrate`, which
+  changes nothing. The answer now says "_main and primary both dump to
+  db/schema.rb, so it may describe primary. Not in main: events._", and asked
+  for that table it says the same, with no word of a migration. 5.35.2 and
+  earlier versions had the gap.
+- **The conventions section says how many entries each of its lists of five
+  leaves out.** `rails_get_config(section: "conventions")` shows the first five
+  authorization checks, denials, flash notices, flash alerts and not-found
+  patterns, and now ends a longer list with `- _...and N more._`. Every earlier
+  version cut each list at five and said nothing about the rest.
+- **`rails_runtime_info` shows Sidekiq's queue counts as the app's only when
+  Sidekiq is the Active Job adapter.** Under another adapter the jobs section
+  says live queue stats are only read from Sidekiq and names that adapter. When
+  the app also has Sidekiq workers of its own, Sidekiq's counts follow under a
+  `### Sidekiq` heading that says they are those workers' counts. Since 4.3.1
+  any app with Sidekiq loaded got Sidekiq's counts under the adapter's name,
+  where they read as that adapter's queue.
+
 ## [5.35.2] - 2026-10-14
 
 ### Security
@@ -8440,7 +8616,7 @@ Every introspector that scans `.rb` files has been migrated from regex-based pat
 
 ### Added - 8 new introspectors closing RAILS_NERVOUS_SYSTEM.md gaps
 
-An audit against [`RAILS_NERVOUS_SYSTEM.md`](RAILS_NERVOUS_SYSTEM.md) identified 9 framework sections where introspection was missing or partial. This release ships the 8 introspectors needed to close them (the 9th - §11 Query interface - was already covered by `:conventions` via `load_async` / `.async_*` scanning). All are wired into `PRESETS[:full]`. The gem now exposes **39 introspectors** (up from 31).
+An audit against `RAILS_NERVOUS_SYSTEM.md` identified 9 framework sections where introspection was missing or partial. This release ships the 8 introspectors needed to close them (the 9th - §11 Query interface - was already covered by `:conventions` via `load_async` / `.async_*` scanning). All are wired into `PRESETS[:full]`. The gem now exposes **39 introspectors** (up from 31).
 
 - **`InitializerIntrospector` (`:initializers`, §2).** Enumerates `Rails.application.initializers` - every initializer's name, owner, declared `before:` / `after:` ordering edges, and the `source_location` of its block. Also summarizes each `config/initializers/*.rb` file (initializer count + the top `config.*` setters it touches) so AI can jump straight to user-owned boot code.
 - **`AutoloadIntrospector` (`:autoload`, §3).** Zeitwerk presence, both `Rails.autoloaders.main` and `.once` with their collapsed dirs + ignored paths + root dirs, raw `autoload_paths` / `autoload_once_paths` / `eager_load_paths`, the resolved `eager_load` boolean, plus custom inflection rules extracted from `config/initializers/*.rb` (`inflect.acronym` / `.plural` / `.singular` / `.irregular` / `.uncountable` / `.human`). Paths are root-relative.

data/CONTRIBUTING.md

@@ -109,6 +109,7 @@ RAC_TEST_MYSQL_URL=trilogy://root:secret@127.0.0.1:3306/rac \
 The specs create and drop tables and views whose names start with `rac_`, and leave the `postgres_fdw` extension installed on PostgreSQL, so point them at a scratch database.
 CI's `database_servers` job runs them on PostgreSQL 16 in every leg. Rails 8.0 runs two legs: MySQL 8.0 with MariaDB 10.6, and MySQL 8.4 with MariaDB 11.4. Rails 7.0 runs MySQL 8.0 with MariaDB 10.6, and Rails 8.1 runs MySQL 8.4 with MariaDB 11.4.
 Rails 7.0 has no Trilogy adapter, so its leg runs PostgreSQL and mysql2 only.
+The `postgresql_versions` job runs the PostgreSQL specs on PostgreSQL 13, 14, 15, 17 and 18 on Rails 8.0, since the plan checks read the plan the server prints.
 The job builds mysql2 against MariaDB's client library (`libmariadb-dev`, through `BUNDLE_BUILD__MYSQL2`), which signs in to MySQL and to MariaDB. A MySQL client from 9.0 on cannot sign in to MariaDB.
 
 ### Static fixture

data/docs/COMPATIBILITY.md

@@ -317,6 +317,12 @@ Proof sources:
    on the v5.35.1 code and on the fixed code, with every changed answer traced
    to its fix; and for each fix an example that fails on the v5.35.1 code, on a
    real server where the fix is a server's.
+   In the v5.36.0 release QA: for each fix an example that fails on the v5.35.2
+   code, on a real server where the fix is a server's; `rails_query` through
+   its tool call in CI on PostgreSQL 16, MySQL 8.0 and 8.4 and MariaDB 10.6 and
+   11.4 on Rails 7.0 (mysql2), 8.0 and 8.1 (mysql2 and Trilogy), and on
+   PostgreSQL 13, 14, 15, 17 and 18 on Rails 8.0; and the unit suite and the
+   E2E harness on Linux, macOS and Windows.
 2. Non-crash coverage for every built-in tool including `get_view` in
    `spec/e2e/in_gemfile_install_spec.rb`'s full-tool sweep; output correctness
    (ivar cross-check, render-form detection, partial interfaces) verified
@@ -363,7 +369,10 @@ row estimates and index usage say they are not available there. CI's
 8.4 and MariaDB 10.6 and 11.4 on Rails 8.0, through mysql2 and Trilogy. It also
 runs PostgreSQL 16 with MySQL 8.0 and MariaDB 10.6 on Rails 7.0, which has no
 Trilogy adapter, and with MySQL 8.4 and MariaDB 11.4 on Rails 8.1; see
-[CONTRIBUTING.md](../CONTRIBUTING.md#real-database-servers).
+[CONTRIBUTING.md](../CONTRIBUTING.md#real-database-servers). The
+`postgresql_versions` job runs the PostgreSQL examples on PostgreSQL 13, 14,
+15, 17 and 18 as well, since the plan checks read the plan the server prints and
+its shape changes between major versions.
 
 Postgres itself - live query safety (read-only transactions, the
 `BLOCKED_FUNCTIONS` guard against `pg_read_file`/`dblink`/`COPY ... PROGRAM`,

data/docs/SECURITY.md

@@ -62,7 +62,7 @@ Before any query reaches the database, the SQL gate (`RailsAiContext::SqlGate`)
 - **Blocks file and network functions**, each on the database family that has it. PostgreSQL: `pg_read_file`, `pg_read_binary_file`, `pg_ls_dir`, `pg_stat_file`, `lo_import`, `lo_export`, `dblink*` and their relatives. MySQL and MariaDB: `LOAD DATA` and `LOAD_FILE`. SQLite: `load_extension`. They are checked before and after comment stripping
 - **Blocks functions that return a whole table as one value**: PostgreSQL's `table_to_xml`, `query_to_xml`, `cursor_to_xml`, `schema_to_xml`, `database_to_xml` and their `_to_xmlschema` and `_to_xml_and_xmlschema` relatives. Such a value carries every column of the table, its secret columns included, under a name no column check reads. The name with `(` after it is refused on the raw text: "Blocked: function <name> returns a whole table as one value, secret columns included. SELECT the columns you need from the table itself."
 - **Blocks relations and settings that hold sampled values, other sessions' statements or stored credentials**: no check on a column's name applies to what they hold, so they are not read at all. "Relations and settings that are never read" below lists them by database family, and each name is refused on the family that has it
-- **On SQLite, blocks functions that tell of the connection**: `rails_query` runs a statement on a connection of its own and sets some of that connection's values itself, so such an answer would not be the app's. A `pragma_*` function runs only when it describes the schema or the database file: `pragma_table_info`, `pragma_table_xinfo`, `pragma_table_list`, `pragma_index_list`, `pragma_index_info`, `pragma_index_xinfo`, `pragma_foreign_key_list`, `pragma_foreign_key_check`, `pragma_integrity_check`, `pragma_quick_check`, `pragma_user_version`, `pragma_application_id`, `pragma_schema_version`, `pragma_page_size`, `pragma_page_count`, `pragma_freelist_count`, `pragma_encoding`, `pragma_auto_vacuum`, `pragma_journal_mode`, `pragma_compile_options` and `pragma_pragma_list`. Every other `pragma_*` name is refused wherever it stands, inside a string literal too, and so is a call of `changes()`, `total_changes()` or `last_insert_rowid()`. The answer is "Blocked: `<name>` tells of the connection that runs it. rails_query runs a statement on a connection of its own and sets some of that connection's values itself, so the answer would not be the app's. A pragma function that describes the schema or the database file runs, for example `pragma_table_info`." An app table whose own name starts with `pragma_` runs
+- **On SQLite, blocks functions that tell of the connection**: `rails_query` runs a statement on a connection of its own and sets some of that connection's values itself, so such an answer would not be the app's. A `pragma_*` function runs only when it describes the schema or the database file: `pragma_table_info`, `pragma_table_xinfo`, `pragma_table_list`, `pragma_index_list`, `pragma_index_info`, `pragma_index_xinfo`, `pragma_foreign_key_list`, `pragma_foreign_key_check`, `pragma_integrity_check`, `pragma_quick_check`, `pragma_user_version`, `pragma_application_id`, `pragma_schema_version`, `pragma_page_size`, `pragma_page_count`, `pragma_freelist_count`, `pragma_encoding`, `pragma_auto_vacuum`, `pragma_journal_mode`, `pragma_compile_options` and `pragma_pragma_list`. Every other `pragma_*` name is refused where SQLite reads it as the function: called, or where a table stands (after `FROM`, `JOIN`, `IN`, a comma of a `FROM` list, a parenthesis that opens one, or a schema's dot there), quoted or in a string literal too. A call of `changes()`, `total_changes()` or `last_insert_rowid()` is refused wherever it stands, inside a string literal too, whatever tables the app has. The answer is "Blocked: `<name>` tells of the connection that runs it. rails_query runs a statement on a connection of its own and sets some of that connection's values itself, so the answer would not be the app's. A pragma function that describes the schema or the database file runs, for example `pragma_table_info`." A view the statement names, and every view its definition names in turn, is read the same way, since SQLite runs its definition on the same connection. Such a view is refused with "Blocked: `<name>`, which the view `<view>` reads, tells of the connection that runs it." and the rest of the sentence above. A view over a pragma function that describes the schema or the database file runs. An app table whose own name starts with `pragma_` runs, since SQLite reads the table under that name, and so does a column whose own name starts with `pragma_`
 - **On SQLite, blocks the tables that hold another table's rows under other names**: the page modules, a shadow table of a virtual table, and a virtual table that holds a secret column. See Layer 4
 - **Blocks a function called by a quoted name**: a quoted name can spell any function, past every check in this list that reads a function's name. A name in double quotes, backticks or brackets with `(` after it is refused on every family, a `U&"..."` name with `UESCAPE` included. The answer is "Blocked: a quoted name is followed by a parenthesis, the way a function is called. rails_query reads a function's name to decide whether it runs, so write the name without quotes." A quoted column inside a call (`count("id")`) and a quoted table before `USING (...)` run
 - **Blocks session-effecting / administrative functions**: a read-only transaction does not stop these, and their effect lingers on the pooled connection, so a call is matched on the raw text: the name with `(` after it is refused, inside a string literal too. A bare name inside a literal is data. PostgreSQL: `pg_terminate_backend`, `pg_cancel_backend`, `pg_reload_conf`, `pg_stat_reset*`, `pg_switch_wal`, `pg_create_restore_point`, replication-slot and -origin functions, `pg_logical_emit_message`, `pg_advisory_lock*`, `set_config`, `pg_notify`, `txid_current` and their relatives; MySQL and MariaDB: `GET_LOCK`, `RELEASE_LOCK`, `RELEASE_ALL_LOCKS`, `IS_FREE_LOCK`, `IS_USED_LOCK`, `MASTER_POS_WAIT`, `SOURCE_POS_WAIT`. Each list is held to its own family. This name list is the first layer; on PostgreSQL the plan's VOLATILE-function check (below) closes the rest of the family
@@ -84,14 +84,14 @@ The textual layer cannot see a whole-row serialisation (`SELECT row_to_json(u.*)
 - calls a function that returns a whole table as one value, or reads a setting that can hold a password (`current_setting` with a refused name, or with a name the plan does not show as one constant);
 - holds a **whole-row reference** (`alias.*`) to a relation that has a secret column - this closes `row_to_json(u)`, `to_json(u)`, `u::text`, `array_agg(u)`, `json_agg(u)`, `hstore(u)`, `concat(u.*)`, `string_agg(u::text, ...)`, a bare `SELECT u`, and the same through a view, subquery or CTE. An alias is read as the plan prints it, so two aliases that differ only by case are two relations. The planner numbers an alias a statement uses twice (`p_1` for the `p` inside a subquery), and that name stands for its own relation alone. The number is taken off only for the members of an Append or a Merge Append, which is how the partitions of one table are named. The refusal names the relation whose row the statement reads;
 - **uses a secret column** anywhere but as a plain pass-through output - a `ROW(u.*)` the planner expanded into named columns, or a `WHERE` / `ORDER BY` oracle, an ordinal `ORDER BY 3` over a wildcard included. The statement a `postgres_fdw` foreign scan sends to the remote server (the plan's `Remote SQL`) is read the same way, so a condition, a sort or a group on a secret column of a foreign table is refused where the remote server would run it. A column that carries another name on the remote server (the `column_name` option) is told by one more catalog read, made only for a plan that holds a foreign scan. A stated limit: only the remote statement of `postgres_fdw` is read, and another foreign data wrapper prints keys of its own. A join that `postgres_fdw` runs on the remote server has one scan for all its tables, which names them with their aliases in its `Relations` line: they are read from there, so a whole row of one is refused and a column of one is traced and filtered like a local table's;
-- **passes a secret column** through an intermediate the plan's top node does not name - a `MATERIALIZED` CTE, a subquery scan, or a set operation (`INTERSECT` / `EXCEPT`) - so its value would reach a result column that the output-provenance redaction (Layer 4) cannot pin. These are refused, since no redaction could reach them. A column that a scan hands to an aggregate or a join is counted only when that node names it, so `count(*)` over a table with a secret column runs;
-- names any **VOLATILE function** (`pg_proc.provolatile = 'v'`) outside a short read-only allowlist. `pg_proc` marks a function VOLATILE when its answer may change within one statement, which is as true of a reader of live server state as of a writer, so VOLATILE alone does not mean "changes state". The allowlist holds only built-in C functions that write nothing: value generators (`random`, `clock_timestamp`, `gen_random_uuid`, `timeofday`, `uuid_generate_v4`, and `pg_sleep*`, which the statement timeout bounds); the size readers (`pg_total_relation_size`, `pg_relation_size`, `pg_table_size`, `pg_indexes_size`, `pg_database_size`, `pg_tablespace_size`); the lock-table snapshot readers (`pg_lock_status` - what the `pg_locks` view reads - `pg_blocking_pids`, `pg_safe_snapshot_blocking_pids`); and the recovery / WAL-position readers (`pg_is_in_recovery`, `pg_is_wal_replay_paused`, `pg_get_wal_replay_pause_state`, `pg_current_wal_lsn`, `pg_current_wal_insert_lsn`, `pg_current_wal_flush_lsn`, `pg_last_wal_receive_lsn`, `pg_last_wal_replay_lsn`, `pg_last_xact_replay_timestamp`). The functions the statement's text names are checked beside those the plan prints, since a plan prints no row of a `VALUES` list and no `LIMIT` expression. Anything else VOLATILE is not run, and the refusal says plainly that the function is VOLATILE and outside the read-only list. This closes the admin-function family without a name list that has to grow with every PostgreSQL release.
+- **passes a secret column** through an intermediate the plan's top node does not name - a `MATERIALIZED` CTE, a subquery scan, or a set operation (`INTERSECT` / `EXCEPT`) - so its value would reach a result column that the output-provenance redaction (Layer 4) cannot pin. These are refused, since no redaction could reach them. A column that a scan hands to an aggregate, a join or a Result node is counted only when that node names it, so `count(*)` over a table with a secret column runs, and so does an `EXISTS` inside an `EXISTS`, whose plan puts a Result over the inner scan;
+- names any **VOLATILE function** (`pg_proc.provolatile = 'v'`) outside a short read-only allowlist. `pg_proc` marks a function VOLATILE when its answer may change within one statement, which is as true of a reader of live server state as of a writer, so VOLATILE alone does not mean "changes state". The allowlist holds only built-in functions and extension C functions that write nothing: value generators (`random`, `clock_timestamp`, `gen_random_uuid`, `timeofday`, `uuid_generate_v4`, and `pg_sleep*`, which the statement timeout bounds); the size readers (`pg_total_relation_size`, `pg_relation_size`, `pg_table_size`, `pg_indexes_size`, `pg_database_size`, `pg_tablespace_size`); the lock-table snapshot readers (`pg_lock_status` - what the `pg_locks` view reads - `pg_blocking_pids`, `pg_safe_snapshot_blocking_pids`); and the recovery / WAL-position readers (`pg_is_in_recovery`, `pg_is_wal_replay_paused`, `pg_get_wal_replay_pause_state`, `pg_current_wal_lsn`, `pg_current_wal_insert_lsn`, `pg_current_wal_flush_lsn`, `pg_last_wal_receive_lsn`, `pg_last_wal_replay_lsn`, `pg_last_xact_replay_timestamp`); and `pg_sequence_last_value`, which reads a sequence's stored value the way `SELECT last_value FROM a_sequence` does and is what the `pg_sequences` view reads. A name on the list vouches for the server's own function and an extension's C function alone, such as `uuid_generate_v4`: while the database holds a VOLATILE function of that name in another language outside `pg_catalog`, every call of the name is refused. The functions the statement's text names are checked beside those the plan prints, since a plan prints no row of a `VALUES` list and no `LIMIT` expression. The name after `TABLESAMPLE` is a sampling method, whose handler the statement never calls, so it is not read as a call; the method's arguments and its `REPEATABLE` seed are, as the plan prints them. Anything else VOLATILE is not run, and the refusal says plainly that the function is VOLATILE and outside the read-only list, or, for a name on the list, that the database holds another VOLATILE function of that name. This closes the admin-function family without a name list that has to grow with every PostgreSQL release.
 
-Every statement except `SHOW` is planned, and an `EXPLAIN` is planned as the statement it explains. A statement whose plan cannot be read does not run: when planning times out the answer is the timeout, when planning fails it is the SQL error, and when the server returns no plan the statement is refused.
+Every statement except `SHOW` is planned, and an `EXPLAIN` is planned as the statement it explains. `EXPLAIN (GENERIC_PLAN)` is planned with that option too, read as the server reads it (its last value, quoted or not), so a statement with `$1` in it is planned as PostgreSQL 16 and later plan it. A statement whose plan cannot be read does not run: when planning times out the answer is the timeout, when planning fails it is the SQL error, and when the server returns no plan the statement is refused.
 
 A whole-row read of a relation with no secret column (`row_to_json(posts.*)`) is allowed. Before these checks scan a plan expression, its string constants are masked (PostgreSQL's deparser always doubles quotes and never emits an `E''` string, so a constant is matched exactly), so a secret word inside a `'%key%'::text` filter or a literal argument is not mistaken for a column or a function.
 
-A subquery or a join over a table that holds a secret column runs when it reads none of them. A scan under an aggregate or a join hands up every column of its table, and the plan check counts a secret column only when the aggregate or the join names it. So `SELECT (SELECT count(*) FROM users) AS n`, `count(id)`, `max(id)` and `EXISTS (SELECT 1 FROM users)` run, while `max(api_token)`, `count(api_token)`, `string_agg(api_token, ',')`, `row_to_json(users)`, a whole row and `count(users)` are refused.
+A subquery or a join over a table that holds a secret column runs when it reads none of them. A scan under an aggregate, a join or a Result node hands up every column of its table, and the plan check counts a secret column only when that node names it. So `SELECT (SELECT count(*) FROM users) AS n`, `count(id)`, `max(id)` and `EXISTS (SELECT 1 FROM users)` run, while `max(api_token)`, `count(api_token)`, `string_agg(api_token, ',')`, `row_to_json(users)`, a whole row and `count(users)` are refused.
 
 #### Relations and settings that are never read
 
@@ -166,13 +166,15 @@ Stated limits of the time bound:
 
 A database leased by name connects with the `connect_timeout` of its `config/database.yml` entry, or `query_timeout` rounded up to whole seconds when the entry sets none, so a server that never answers the connection ends the call. On MySQL and MariaDB such a connection also gets a `read_timeout` of twice `query_timeout` plus 5 seconds unless its entry sets one, so a server that goes silent after the handshake ends the call. On PostgreSQL `connect_timeout` is the only client bound. Taking the lease down does not replace the outcome of the call: its connections are thrown away and its pool removed, and an error there is not raised. The primary uses the app's own pool and its settings.
 
-The MySQL session variable bounds a statement that starts with `WITH` or `EXPLAIN ANALYZE` too; the `MAX_EXECUTION_TIME` hint binds only the outermost `SELECT`, so it is not used. `query_timeout` is a positive number, and PostgreSQL, MySQL and MariaDB bound a value under a millisecond at one millisecond. A timeout is read from the error's class or the database's native code alone, so an SQL error whose message names a column called `timeout` is reported as an SQL error. A wait that PostgreSQL's own `lock_timeout` ended is answered as the timeout. A connection the server dropped is no timeout: on Rails 7.1 and later the answer is an error that starts "The <name> database stopped answering during the query:".
+The MySQL session variable bounds a statement that starts with `WITH` or `EXPLAIN ANALYZE` too; the `MAX_EXECUTION_TIME` hint binds only the outermost `SELECT`, so it is not used. `query_timeout` is a positive number, and PostgreSQL, MySQL and MariaDB bound a value under a millisecond at one millisecond. A timeout is read from the error's class or the database's native code alone, so an SQL error whose message names a column called `timeout` is reported as an SQL error. On PostgreSQL a statement another session cancels (`pg_cancel_backend`) raises the timeout's class too, and the server's message alone tells them apart: a cancel, whose message ends "due to user request", is answered as the SQL error it is. A server that writes its messages in another language answers such a cancel as the timeout. A wait that PostgreSQL's own `lock_timeout` ended is answered as the timeout. A connection the server dropped is no timeout: on Rails 7.1 and later the answer is an error that starts "The <name> database stopped answering during the query:".
 
 On MySQL and MariaDB the session that holds the read-only transaction and the time limit is the only one the statement is sent on. Rails replaces a connection it lost before the transaction begins, and the new session has neither guard. So the session's id is read inside the transaction, with one `SELECT CONNECTION_ID()`, and compared with the one the limits were set on. When they differ the answer is "The <name> database stopped answering during the query: the connection was replaced before the statement was sent, and the new session has no read-only transaction and no time limit, so the statement was not sent".
 
 On PostgreSQL and MySQL the query executes inside a transaction, then rolls back (even if it could write, it can't). MySQL's read-only transaction still lets `FOR SHARE`, `LOCK IN SHARE MODE` and `INTO` through, so the Layer 1 checks stay on every family.
 
-On a connection that is already inside a transaction (a tool called from a transactional test, a mounted server inside a request's transaction) the guard leaves that transaction as it found it. PostgreSQL guards inside a savepoint, so the outer transaction stays writable. MySQL and MariaDB cannot make an open transaction read-only, so the statement is not sent and the answer is "Query failed: MySQL cannot make a transaction that is already open read-only, so the statement was not sent. Run it outside the transaction." SQLite runs the statement on the app's own connection, so it reads the rows of the open transaction. It runs under `PRAGMA query_only = ON`, and the pragma is put back as it was found.
+On a connection that is already inside a transaction (a tool called from a transactional test, a mounted server inside a request's transaction, a transaction the app opened with a raw `BEGIN` that Active Record does not count) the guard leaves that transaction open as it found it, with its writes. PostgreSQL guards inside a savepoint, chosen by the server's own transaction status, so the outer transaction stays writable. MySQL and MariaDB cannot make an open transaction read-only: the server refuses `SET TRANSACTION READ ONLY` inside one, and a `BEGIN` there would commit it, so no `BEGIN` is sent, the statement is not sent, and the answer is "Query failed: MySQL cannot make a transaction that is already open read-only, so the statement was not sent. Run it outside the transaction." SQLite runs the statement on the app's own connection, so it reads the rows of the open transaction. It runs under `PRAGMA query_only = ON`, and the pragma is put back as it was found.
+
+A statement that reads a setting the guard sets for it answers the guard's value: `statement_timeout` and `transaction_read_only` on PostgreSQL, the statement limit (`max_execution_time` or `max_statement_time`) and `lock_wait_timeout` on MySQL and MariaDB. When the statement reads one of them (`SHOW name`, `@@name`, `@@SESSION.name`, `@@LOCAL.name` or `current_setting('name')`, the name backquoted or not), or a `SHOW VARIABLES` row or MariaDB's `information_schema.SESSION_VARIABLES` names one, the answer ends with a note that says so and gives the session's own value, for example "statement_timeout here is the value rails_query sets for each statement it runs. The session's own: statement_timeout 50s." A name used as an alias or a column, one in a string or a comment, and a global value on MySQL and MariaDB get no note. SQLite's `PRAGMA query_only` is refused by name.
 
 An adapter with no family (SQL Server, Oracle, CockroachDB and any other) is refused: `rails_query` answers with the adapter's name and sends no statement, because it cannot give that database a read-only transaction and a timeout it has verified. The family is read from the database's configuration, so the refusal comes before any connection is opened or verified. CockroachDB's adapter is built on PostgreSQL's, but the adapter's name alone chooses the family, so it is refused too.
 
@@ -256,7 +258,7 @@ minus anything in `config.query_allowed_columns`. An `encrypts` column is the ex
 
 **Default redacted patterns:** `password_digest`, `encrypted_password`, `password_hash`, `reset_password_token`, `confirmation_token`, `unlock_token`, `otp_secret`, `session_data`, `secret_key`, `api_key`, `api_secret`, `access_token`, `refresh_token`, `jti`. Those are the defaults of `config.query_redacted_columns`. The fixed built-in list adds `password_reset_token`, `remember_token`, `secret`, `private_key`, `authentication_string`, `rolpassword` and `setconfig`. The last three are where MySQL and PostgreSQL keep password hashes and stored settings.
 
-The pre-execution refusal matches on two things, as whole identifiers. Names are folded the way the databases compare them: lowercase, with MySQL's reading of a dotted capital I as `i`.
+The pre-execution refusal matches on two things, as whole identifiers. Names are folded the way the databases compare them. On SQLite that is ASCII letters alone, so `"é"` and `"É"` are two columns there and a refusal of one leaves the other. On PostgreSQL, MySQL and MariaDB every letter is folded to lowercase, with MySQL's reading of a dotted capital I as `i`, since a collation or a database encoding can fold more than ASCII there, and a false refusal is the safe side. What a name means is read with every letter folded on every family: a column whose name folds to a built-in name or to one the heuristic flags is a secret column, and so is one a configured name folds to when no column of the database spells that name as the database folds it.
 
 - **the fixed names above**, on every family whether or not they are real columns;
 - **every real column of your schema that the rule flags** - read from the connection the query runs on, so a database named with `database` is checked against its own columns. This catches an app-specific column the heuristic flags (`api_token`, `auth_token`) through any alias or expression. Rails' own bookkeeping tables (`ar_internal_metadata`, `schema_migrations`) are left out: their columns hold no secrets, and `ar_internal_metadata.key` ends in "key", so counting it would refuse every query whose text held the word "key".
@@ -271,7 +273,7 @@ The rule follows what a statement reaches. It starts from these columns, by data
 
 A schema or database is told by a name before a dot, and the server says which of those names are schemas. Each name is read backward from its dot, bare or in backticks or double quotes, so nothing written before the name changes how it is read, a quote character inside a string included. A name in brackets is not read: SQLite reads every schema whatever a statement names, and on MySQL and MariaDB Layer 1 refuses the bracket. A view the statement names can name a further schema or database in its definition, and a view named there a further one. The rule follows those views three reads deep. A view no statement names is not followed, so a statement that names no other schema or database and no such view costs no extra read. On PostgreSQL the plan reads through a plain view, so only a materialized view's definition is followed. A statement that names a view that leads deeper is not run: "The view `<view>` leads through more databases than rails_query follows, so the secret columns it could read cannot be told and no statement that names it runs." On PostgreSQL the sentence says "schemas". A schema whose columns cannot be read stops the statement too: "The columns of `<name>` could not be read, so the secret columns there cannot be told and no query that reads it runs." On PostgreSQL a relation the plan names and the rule could not read is refused by the plan check of Layer 1b. So a statement that names a secret column of a table in another schema or database is refused by name, as one in the connection's own is.
 
-A refusal names a view, a table or a relation as the database spells it. The rule itself compares names case folded, with a run of spaces as one space. So two names that differ by a run of spaces alone are one name to the rule, and a refusal names the first of them it read.
+A refusal names a view, a table or a relation as the database spells it. The rule itself compares names case folded as above, with a run of spaces as one space. So two names that differ by a run of spaces alone are one name to the rule, and a refusal names the first of them it read.
 
 The schema read fails closed. When the columns of the database cannot be read, no query runs on it and the answer is "The columns of the <name> database could not be read, so its secret columns cannot be told and no query runs on it." Only the primary falls back to the cached context's schema, and it is refused the same way when that has no tables either.
 

data/docs/TOOLS.md

@@ -147,10 +147,7 @@ dump was not read is named with "(tables not read)" and left out of the table
 count, and the summary says so: "5 tables in 2 databases, the warehouse
 database not read". It ends with the app's custom rake tasks (Rakefile,
 `lib/tasks`, `rakelib`), each with its arguments, description and file: the
-first 15 at `standard`, every one at `full`. A known limit: on
-`preset: standard` on the static tier the stack line reads the primary's
-adapter as `unknown`, and a database's heading in the generated files can name
-no adapter.
+first 15 at `standard`, every one at `full`.
 Then the app's own generators under `lib/generators` (the `bin/rails generate`
 command and its USAGE line), the `lib/templates` files that replace a built-in
 generator's template, and the Railties under `lib/` with their initializers.
@@ -170,7 +167,10 @@ generator's template, and the Railties under `lib/` with their initializers.
 Database schema with column types, indexes, defaults, encrypted hints. Booted,
 a table `db/schema.rb` declares and the connected database does not have is
 named as a migration that has not run, and the listing header says when the
-two table counts disagree.
+two table counts disagree. Where two databases both dump to `db/schema.rb` (the
+first one and the one named `primary`), the file may hold the other one's
+tables, so such a table is named as not in the connected database, with no
+word of a migration.
 
 The other databases are listed after the primary's tables: every database any
 environment in `config/database.yml` configures, so a Rails 8 app's queue,
@@ -184,10 +184,9 @@ or `schema_format` says.
 A database only another environment configures carries a mark, as in
 `cache (production only)`, and a first database that is not named `primary`
 is listed under its own name where another database is the one named
-`primary`. Both are the same under every `preset`. With the
-`multi_database` introspector off, as on `preset: standard`, `rails_get_schema`,
-`rails_onboard`, `rails_performance_check` and the generated files read them
-from the app databases list.
+`primary`. Both are the same under every `preset`, and so is each database's
+adapter: with the `multi_database` introspector off, as on `preset: standard`,
+the context still carries the app databases list.
 
 Column hints follow the leftmost-prefix rule: `[indexed]` means some index leads
 with the column, so a lookup on it alone can use one; `[unique]` means a unique
@@ -655,7 +654,7 @@ ViewComponent/Phlex components: props, slots, previews, sidecar assets, usage ex
 
 ### `rails_get_mailers`
 
-ActionMailer mailers: every mailer class with its delivery actions and delivery method. A mailer that declares no action of its own - one taking them from a gem base or a mixin, or one called through class methods - is listed with where its actions come from rather than left out. A base other mailers inherit from is not one: it leaves the listing, and a line above names the ones left out. Asked for by name, a base answers with what every mailer below it inherits - its layout, helpers, defaults, callbacks and mixins as the app wrote them, the methods it defines - and which mailers inherit it.
+ActionMailer mailers: every mailer class with its delivery actions and delivery method. The actions include the public methods a mailer inherits from the app's own mailers below `ApplicationMailer`, on both tiers. A mailer that declares no action of its own - one taking them from a gem base or a mixin, or one called through class methods - is listed with where its actions come from. A base other mailers inherit from is not one: it leaves the listing, and a line above names the ones left out. Asked for by name, a base answers with what every mailer below it inherits - its layout, helpers, defaults, callbacks and mixins as the app wrote them, the methods it defines - and which mailers inherit it.
 
 Each mailer also shows its own `default`, `layout`, `helper` and action and
 deliver callbacks as written, the template formats of each action under
@@ -834,6 +833,8 @@ Table sizes come from PostgreSQL, MySQL (base tables only) and SQLite, and index
 
 The pool and the cache are read inside the MCP server process, and the answer says so: the pool's counts are that process's own connections, and a `MemoryStore`'s entries are its own, since each app server process holds its own. A store the processes share (Redis, Memcached, Solid Cache, a file store) is the app's. Another environment that configures a shared store is named, as where the app's cache lives there. Solid Cache's stats are read from its database, so when that is a SQLite file that is not there, the cache section says the database does not exist yet and creates nothing.
 
+The jobs section names the Active Job adapter the running environment uses. Queue counts are read from Sidekiq alone: they are the app's when Sidekiq is that adapter, and under another adapter they are shown under their own heading only when the app has Sidekiq workers of its own, as those workers' counts.
+
 | Parameter | Type | Default | Description |
 |:----------|:-----|:--------|:------------|
 | `detail` | enum | `standard` | `summary`, `standard`, `full` |

data/docs/TROUBLESHOOTING.md

@@ -311,7 +311,7 @@ A view over one of these is refused with "its definition names `<table>`, which
 
 ### "Blocked: `pragma_foreign_keys` tells of the connection that runs it"
 
-On SQLite `rails_query` runs a statement on a connection of its own, so a value that belongs to a connection would not be the app's. The pragma functions that describe the schema or the database file run: `pragma_table_info`, `pragma_index_list`, `pragma_foreign_key_list`, `pragma_integrity_check`, `pragma_page_count` and the others [SECURITY.md](SECURITY.md#layer-1---the-sql-gate-statement-checks) lists. Every other `pragma_*` function is refused, and so are `changes()`, `total_changes()` and `last_insert_rowid()`. Read those on the app's own connection, in `bin/rails runner` or the console. A `pragma_*` name is refused wherever it stands, so a column whose own name starts with `pragma_` is refused too: read it in the console as well.
+On SQLite `rails_query` runs a statement on a connection of its own, so a value that belongs to a connection would not be the app's. The pragma functions that describe the schema or the database file run: `pragma_table_info`, `pragma_index_list`, `pragma_foreign_key_list`, `pragma_integrity_check`, `pragma_page_count` and the others [SECURITY.md](SECURITY.md#layer-1---the-sql-gate-statement-checks) lists. Every other `pragma_*` function is refused, and so are `changes()`, `total_changes()` and `last_insert_rowid()`. Read those on the app's own connection, in `bin/rails runner` or the console. A column whose own name starts with `pragma_` runs. Its name is refused only where SQLite would read the function: called, or where a table stands.
 
 ### "Blocked: the statement is ... bytes long"
 

data/lib/rails_ai_context/database_family/mysql_runtime.rb

@@ -7,6 +7,9 @@ module RailsAiContext
     module MysqlRuntime
       module_function
 
+      # A transaction is open that Active Record does not count, which a BEGIN would commit.
+      TRANSACTION_ALREADY_OPEN = 1568
+
       IN_TRANSACTION = "MySQL cannot make a transaction that is already open read-only, so the statement " \
         "was not sent. Run it outside the transaction."
 
@@ -41,7 +44,13 @@ module RailsAiContext
       # before the first statement in the block. Unscoped, it applies to the next transaction only.
       def in_read_only_transaction(conn, sql, session)
         result = nil
-        conn.execute("SET TRANSACTION READ ONLY")
+        begin
+          conn.execute("SET TRANSACTION READ ONLY")
+        rescue ActiveRecord::StatementInvalid => e
+          raise Unsupported, IN_TRANSACTION if DatabaseFamily.native_code(e) == TRANSACTION_ALREADY_OPEN
+
+          raise
+        end
         conn.transaction do
           # Rails replaces a connection it lost before BEGIN, and a new session has neither guard.
           raise ActiveRecord::ConnectionNotEstablished, REPLACED unless conn.select_value("SELECT CONNECTION_ID()").to_i == session.to_i
@@ -52,6 +61,12 @@ module RailsAiContext
         result
       end
 
+      # The settings bounded sets for each statement => the read of the session's own value.
+      def bound_settings(conn)
+        limit = conn.mariadb? ? "max_statement_time" : "max_execution_time"
+        { limit => "SELECT @@SESSION.#{limit}", "lock_wait_timeout" => "SELECT @@SESSION.lock_wait_timeout" }
+      end
+
       def explain(conn, sql, timeout)
         # MySQL 8.3+ defaults to TREE output, which has no table/type/key columns. MariaDB has no FORMAT=TRADITIONAL.
         prefix = conn.mariadb? ? "EXPLAIN" : "EXPLAIN FORMAT=TRADITIONAL"
@@ -90,7 +105,7 @@ module RailsAiContext
         []
       end
 
-      def plan(_conn, _sql, _timeout)
+      def plan(_conn, _sql, _timeout, **)
         nil
       end
 

data/lib/rails_ai_context/database_family/postgresql_plan.rb

@@ -10,11 +10,15 @@ module RailsAiContext
       NAME = /(?:([A-Za-z_]\w*)|"((?:""|[^"])+)")/
       BASE_VAR = /\A#{NAME}\.#{NAME}\z/
       # Nodes whose every read of a child's column is an expression of their own that names it.
-      READS_BY_NAME = [ "Aggregate", "Hash Join", "Merge Join", "Nested Loop" ].freeze
+      READS_BY_NAME = [ "Aggregate", "Hash Join", "Merge Join", "Nested Loop", "Result" ].freeze
 
       # Catalogs and TOAST tables: the never-read list and the catalog credentials hold what is secret there.
       SYSTEM_SCHEMA = /\A(?:pg_catalog|information_schema|pg_toast(?:_temp_\d+)?)\z/
 
+      # Before PostgreSQL 15 a plan names the session's temporary schema by its number, where the catalog reads say pg_temp.
+      # Another session's temporary table can be planned but never read, so a statement over one fails when it runs.
+      OWN_TEMP_SCHEMA = /\Apg_temp_\d+\z/
+
       APPENDS = [ "Append", "Merge Append" ].freeze
       REMOTE_NAME = /"(?:""|[^"])+"|[^\s()."]+/
       REMOTE_RELATION = /\((?:(#{REMOTE_NAME})\.)?(#{REMOTE_NAME})(?: (#{REMOTE_NAME}))?\)/
@@ -95,7 +99,7 @@ module RailsAiContext
       # no relation of its own: postgres_fdw names its tables there, each with its alias, as `(schema.table alias)`.
       def scanned(node)
         rel = node["Relation Name"]
-        return [ [ node["Schema"], rel.to_s, (node["Alias"] || rel).to_s ] ] if rel
+        return [ [ node["Schema"]&.sub(OWN_TEMP_SCHEMA, "pg_temp"), rel.to_s, (node["Alias"] || rel).to_s ] ] if rel
 
         node["Relations"].to_s.scan(REMOTE_RELATION).map do |parts|
           schema, name, as = parts.map { |part| part&.delete_prefix('"')&.delete_suffix('"')&.gsub('""', '"') }

data/lib/rails_ai_context/database_family/postgresql_runtime.rb

@@ -9,6 +9,12 @@ module RailsAiContext
       module_function
 
       def read_only(conn, sql, timeout)
+        # An EXPLAIN answers text, and one of a generic plan holds $1, which Rails 7.0's select_all sends as an empty bind.
+        if sql.match?(/\A\s*EXPLAIN\b/i)
+          result = bounded(conn, timeout) { conn.execute(sql) }
+          return Rows.new(result.fields, result.values, false)
+        end
+
         result = bounded(conn, timeout) { conn.select_all(sql) }
         Rows.new(result.columns, result.rows, false)
       end
@@ -18,16 +24,41 @@ module RailsAiContext
       def bounded(conn, timeout)
         result = nil
         DatabaseFamily.bounding do
-          conn.transaction(requires_new: true) do
+          rolling_back(conn) do
             conn.execute("SET TRANSACTION READ ONLY")
             conn.execute("SET LOCAL statement_timeout = '#{[ (timeout * 1000).to_i, 1 ].max}'")
             result = yield
-            raise ActiveRecord::Rollback
           end
         end
         result
       end
 
+      # PG::PQTRANS_IDLE, which needs the pg gem loaded.
+      TRANSACTION_IDLE = 0
+
+      # The server's own transaction status decides: Active Record does not count a transaction the app opened with a
+      # raw BEGIN, and its own BEGIN and ROLLBACK there would end the app's.
+      def rolling_back(conn)
+        if conn.raw_connection.transaction_status == TRANSACTION_IDLE
+          conn.transaction(requires_new: true) do
+            yield
+            raise ActiveRecord::Rollback
+          end
+        else
+          conn.execute("SAVEPOINT rac_bounded")
+          begin
+            yield
+          ensure
+            DatabaseFamily.restore(conn, "ROLLBACK TO SAVEPOINT rac_bounded; RELEASE SAVEPOINT rac_bounded")
+          end
+        end
+      end
+
+      # The settings bounded sets for each statement => the read of the session's own value.
+      def bound_settings(_conn)
+        { "statement_timeout" => "SHOW statement_timeout", "transaction_read_only" => "SHOW transaction_read_only" }
+      end
+
       def explain(conn, sql, timeout)
         raw = read_only(conn, "EXPLAIN (FORMAT JSON, ANALYZE) #{sql}", timeout).rows.map { |r| r.first.to_s }.join("\n")
         scans = []
@@ -44,8 +75,8 @@ module RailsAiContext
 
       # Planning only: EXPLAIN without ANALYZE runs nothing, not even a VOLATILE function.
       # A timeout and an SQL error are raised, so the caller never runs what it could not plan.
-      def plan(conn, sql, timeout)
-        json = read_only(conn, "EXPLAIN (VERBOSE, FORMAT JSON) #{sql}", timeout).rows.first&.first
+      def plan(conn, sql, timeout, generic: false)
+        json = read_only(conn, "EXPLAIN (VERBOSE, FORMAT JSON#{", GENERIC_PLAN" if generic}) #{sql}", timeout).rows.first&.first
         data = JSON.parse(json.to_s)
         data.is_a?(Array) && data.first.is_a?(Hash) ? data.first["Plan"] : nil
       rescue JSON::ParserError
@@ -82,8 +113,12 @@ module RailsAiContext
           [ i, names[col], relation ] if names[col]
         end
       rescue StandardError => e
-        # The driver raises its own class here. Half a trace is no answer, so a timeout is raised as the call's.
-        raise TimedOut, e.message if defined?(PG::QueryCanceled) && e.is_a?(PG::QueryCanceled)
+        # The driver raises its own class here. Half a trace is no answer, so a timeout is raised as the call's, and a cancel as itself.
+        if defined?(PG::QueryCanceled) && e.is_a?(PG::QueryCanceled)
+          raise if DatabaseFamily.canceled?(e)
+
+          raise TimedOut, e.message
+        end
         raise if e.is_a?(ActiveRecord::StatementInvalid) && DatabaseFamily.timed_out?(e)
 
         []

data/lib/rails_ai_context/database_family/sqlite_runtime.rb

@@ -32,8 +32,9 @@ module RailsAiContext
 
       def read_only(conn, sql, timeout)
         deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + timeout
-        # A child opens the file itself and would answer without the rows of a transaction open here.
-        if !conn.transaction_open? && (path = fork_path(conn)) && !DatabaseFamily.bounding { held_here?(conn, sql) }
+        # A child opens the file itself and would answer without the rows of a transaction open here, one the app
+        # opened with a raw BEGIN too, which only the connection itself knows of.
+        if !conn.raw_connection.transaction_active? && (path = fork_path(conn)) && !DatabaseFamily.bounding { held_here?(conn, sql) }
           result = in_child(conn, path, sql, deadline)
           return Rows.new(result.columns, result.rows, false) if result
         end
@@ -85,6 +86,11 @@ module RailsAiContext
         DatabaseFamily.bounding(&reads)
       end
 
+      # PRAGMA query_only, the one setting it sets, is refused by name.
+      def bound_settings(_conn)
+        {}
+      end
+
       def explain(conn, sql, timeout)
         result = read_only(conn, "EXPLAIN QUERY PLAN #{sql}", timeout)
         scans = []
@@ -113,7 +119,7 @@ module RailsAiContext
         []
       end
 
-      def plan(_conn, _sql, _timeout)
+      def plan(_conn, _sql, _timeout, **)
         nil
       end