Keep FOR UPDATE after LIMIT, and check formatting is a fixed point - #68
Conversation
SELECT ctid FROM t ORDER BY a LIMIT 10 FOR UPDATE
-> SELECT ctid FROM t ORDER BY a LIMIT 10
When the locking clause follows LIMIT, the grammar wraps it in
opt_for_locking_clause, which the clause collector did not match. The
output runs and takes no row locks; `LIMIT 1 FOR UPDATE SKIP LOCKED` is
the usual job-queue pattern. Present in v1.4.0 (#67).
The guard missed it because the documentation writes `FOR UPDATE LIMIT
n`, which #59 fixed and renders as `LIMIT n FOR UPDATE`: the lock only
disappeared on a second pass. A new corpus test checks that formatting
every statement twice, in every style, gives the same result. It found
one more: a string constant continued across lines, `'foo'` then `'bar'`
on the next line, gained seven spaces of indentation on every pass. The
parts arrive as one token with the whitespace between them, and layout
indented it again. They are now joined by a bare newline, and layout
supplies the indentation.
Closes #67.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UFqHcQxRwX8CuJaECqiHUz
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: 4 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 6 reviews per hour. 📝 WalkthroughWalkthroughThe formatter now joins continued string literal tokens with newlines and collects locking clauses wrapped after ChangesContinued string literals
Locking clauses after LIMIT
Estimated code review effort: 2 (Simple) | ~12 minutes Merge Risk: ⚪ Minimal · up to No concrete issue remains that would prevent merging after normal checks. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
A rabbit checks the lines of SQL, Comment |
Closes #67.
FOR UPDATE after LIMIT
The locking clause is lost, so a formatted job-queue worker takes no lock. After
LIMITthe grammar wraps it inopt_for_locking_clause, which the clause collector did not match. It is now collected likeopt_select_limit.Fixed-point guard
The corpus writes this as
FOR UPDATE LIMIT n, which #59 fixed and renders asLIMIT n FOR UPDATE, so the lock only disappeared on a second pass, which the guard never ran.formatted_corpus_is_a_fixed_pointintests/token_loss_test.rsnow formats every corpus statement twice in every style and requires the same result.It found one more case: a string constant continued across lines (
'foo'then'bar'on the next line, which PostgreSQL joins) gained seven spaces on every pass. The value was unchanged, since the whitespace sits between the parts, but the output was not stable. The parts are now joined by a bare newline and layout supplies the indentation.The guard now checks three things over the PostgreSQL 19 documentation corpus in all 8 styles: no token loss, output re-parses, and formatting is a fixed point.
🤖 Generated with Claude Code
https://claude.ai/code/session_01UFqHcQxRwX8CuJaECqiHUz
Summary by CodeRabbit
FOR UPDATE SKIP LOCKEDclauses when they followLIMIT.