Issue 193 resolved: both readers live on every machine, checked by asking each copy who it is

04-ISSUES/193-the-store-seats-read-only-query-is-read-only-by-convention/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-02
 located-in: [mesh-catalog modules/postgres/client.ts (readOnlyQuery)]
-fixed-by: [mesh-catalog PR 209 (postgres; open), mesh-catalog PR 210 (mssql; open)]
+fixed-by: [mesh-catalog PR 209 (postgres), mesh-catalog PR 210 (mssql)]
 amended-design:
 ---
 
@@ -97,3 +97,16 @@ the administrators' role were all refused, and the variable came back as the lit
 its own syntax, and a caller's text handed to it is a program in that syntax as well as in SQL.* A
 module that passes a caller's text to a client has two languages to defend, and a transaction drawn
 around the text defends neither.
+
+## Resolved, 2026-10-02
+
+Both pull requests merged, built and pushed to the two machines that run each module. Checked live, on
+every copy, by asking each one who it is:
+
+- the store seat's `query`, and postgres's own tool on each machine, answer as the reader login —
+  not a superuser, in a read-only transaction — with rows keyed by their columns;
+- mssql's tool, on each machine, answers as its reader login, outside the administrators' role, and
+  returns `$(SQLCMDPASSWORD)` as the literal text it is. Its tools work for the first time.
+
+The escapes themselves were tried only on the throwaway servers above; on the live mesh the check is
+the identity a statement runs as, which is what makes every escape a statement that the login cannot do.