[datlechin]

Summary

• The Linux SQL editor edits a query result when the run returns one result, its statement reads one table, and the result carries that table's whole primary key. Insert, duplicate, delete, undo and redo work as in a table tab.
• Saves go through the table tab's path on the window's connection: Confirm Writes, the Read-Only level, row guards, query history, Stop Saving and the close prompts. The statement runs again after a save, as an ordinary run that history leaves out.
• A read-only result says why in the row details: more than one table, grouped or computed rows, a view or temporary table, a missing key, an open or unknown transaction, another database, or a run of several results.
• Core: ResultColumn::origin, sql_syntax::source_table, and edit::{result_source, result_target, parsed_origins, value_for_column} decide editability for every app.
• Drivers set origins only for a direct column of a permanent base table:
  • PostgreSQL resolves the table on the tab's connection under the cursor's lock.
  • MySQL and MariaDB use sqlx's origin plus SHOW CREATE TABLE.
  • SQLite reads sqlite3_column_*_name.
  • SQL Server uses dm_exec_describe_first_result_set.
  • DuckDB and ClickHouse resolve the name on the tab's session; Cassandra and ScyllaDB use the result's table spec.
  • MongoDB and Redis stay read-only.
• Ctrl+S saves changed rows while the results have the focus and the file otherwise; Ctrl+Z and Ctrl+Shift+Z undo and redo rows there.
• The results bar saves rows only; the close prompt saves an editor tab's rows and then its file, once per tab.
• A column the catalog does not know now says "This column can't be written back to the table" (cell_editability test updated).
• ADRs: core 0015, Linux 0036.

Deliberately not fixed here

• MySQL and MariaDB editor results read TIMESTAMP in the session's zone. A row keyed on one stays read-only, and a result holding one offers no Duplicate Row. Reading the instant needs the session's zone, a change to the MySQL editor's decoding.
• PostgreSQL editor results read every value as text. A row keyed on a float, date, time, interval or money column stays read-only, and a result holding such a value offers no Duplicate Row, since extra_float_digits, DateStyle and the like shape that text. Typed reads in the editor would lift both.

Test plan

• Core unit tests: source_table shapes and refusals; result_target key coverage, renamed, duplicated and computed columns, and catalog drift.
• Driver tests per engine for *, alias, expression, view, temporary table, another schema or database, and a user transaction. SQLite and DuckDB run file-backed; PostgreSQL, MySQL, MariaDB, SQL Server, ClickHouse and Cassandra run in docker.
• GTK tests: a traced result edits and its Save reaches the window; a join, a partial key, an open transaction and an untraced result stay read-only with their reason; a run asks before it drops changed rows.
• Local container run: build, lint (rustfmt, clippy with and without default features), tablepro-core result_target and source_table, the SQLite and DuckDB suites, the origin unit tests of every driver, and the app's result editing, results pane, accelerator and close-choice tests pass.
• In the app on SQLite: a SELECT * FROM customers result edits, saves, and shows the saved value after the run that follows the save; a join explains why it is read-only.

Screenshots

Before, a typed value goes nowhere:

After, the change is pending with Save and Discard:

A join says why it is read-only: