require-timeout-settings: explain lock impact in the warning

[edeetee]

Motivation

require-timeout-settings fires on any statement that can wait on a lock, but the message never says which lock the statement takes or what it conflicts with. That flattens a real distinction: ALTER TABLE ... ADD COLUMN takes an ACCESS EXCLUSIVE lock that blocks reads and writes, while COMMENT ON takes a SHARE UPDATE EXCLUSIVE lock that blocks neither — it only contends with VACUUM/ANALYZE/index builds. Same generic message today, so a reader can't tell a potential outage from a catalog write that's effectively free.

What this changes

Classifies statements by the Postgres lock mode they take, then names that lock in the warning and uses it to build the lock_timeout help, so both are keyed off the lock level rather than the statement.

The model is small: a LockMode enum with name() (used to build violation_message()) and help(), plus statement_lock(&stmt) -> LockMode for the classification. This PR wires up SHARE UPDATE EXCLUSIVE (via COMMENT ON); everything else maps to LockMode::Unknown, whose name() is None so the message and help fall back to the original generic text — so every other message and snapshot is unchanged. Same statements are flagged.

Extending

Adding a lock class is a new LockMode variant plus its name()/help() arms, and the statements that map to it in statement_lock. The notable gap is the ACCESS EXCLUSIVE ALTER TABLE variants: their lock depends on the per-action subcommand (ADD COLUMN vs VALIDATE CONSTRAINT vs SET STATISTICS…), so classifying them means descending into alter_table.actions() rather than matching at the Stmt level. Left for a follow-up to keep this reviewable.

Example

warning[require-timeout-settings]: Missing `set lock_timeout` before potentially slow SHARE UPDATE EXCLUSIVE lock operations
 ╭▸ comment.sql:1:1
 │
1│ COMMENT ON COLUMN t.c IS 'an opaque id';
 │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 │
 ├ help: Configure a `lock_timeout` before this statement. It takes a SHARE UPDATE EXCLUSIVE lock. It will block other schema changes (VACUUM, ANALYZE, index builds) but not reads or writes.

Testing

Existing snapshots unchanged; adds err_comment_on_explains_lock_impact, which asserts the COMMENT ON help includes the lock mode (contains("EXCLUSIVE") rather than a snapshot, so it's robust to help-text wrapping).

[netlify]

👷 Deploy request for squawkhq pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	0acb0d1

[sbdchd]

Great idea! Thank you!