[jbylund]

git_sql's read-only guard tested isinstance(expr, exp.Select), and a set operation parses to an exp.SetOperation, so every UNION, EXCEPT and INTERSECT was refused as though it were a write:

git=> SELECT subject FROM commits UNION SELECT subject FROM commits;
ERROR:  this example serves SELECT only -- a git repo is read-only

psql's own \d sends one — the publications footer is three SELECTs joined by UNION.

The guard is now (exp.Select, exp.SetOperation). Deliberately not exp.Query, which would also admit a bare exp.Subquery — (SELECT ...) LIMIT 1, whose LIMIT the executor drops, answering every row instead of one. TableSession repairs that in _flatten_parenthesized; this example has no such layer, so that shape stays refused rather than becoming silently wrong.

The second shape, which has to be refused explicitly

Letting set operations through exposed one that cannot just be allowed. sqlglot's executor answers an ORDER BY over a set operation with the columns stripped — [(), (), ()] — which is not a wrong value but a D message contradicting the RowDescription describe() already sent:

git=> SELECT name FROM branches UNION SELECT name FROM branches ORDER BY 1;
unexpected field count in "D" message

psycopg drops the connection. _reject_stripped_columns turns that into a 0A000 naming the cause. It comes out together with its test when jbylund/sqlglot#34 lands.

Tests

Both run over the wire, because in-process the stripped rows merely look odd and it is the socket that turns them into a protocol violation. Both fail without the fix. _serving() factors out the subprocess-and-connect dance the startup test already did inline.

Full suite: 888 passed, 32 xfailed. ruff check and ruff format --check clean.

Related

While measuring this I found the catalog path has none of tables.py's workarounds at all, so the same class of bug is live on \d — filed as #124. This PR does not touch that; it only stops git_sql calling a UNION a write.