⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 14.28571% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.34%. Comparing base (2ac8fb5) to head (a35a464).

@@            Coverage Diff             @@
##             main     #767      +/-   ##
==========================================
- Coverage   67.35%   67.34%   -0.01%     
==========================================
  Files          52       52              
  Lines       34082    34089       +7     
==========================================
  Hits        22954    22954              
- Misses      11128    11135       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

REV — PR #767

Verdict: APPROVE ✅

Blocking findings

None.

Non-blocking findings

N1 — Unnecessary .clone() in exec_lines (exec_lines path, line 1560) — fixed in follow-up commit a35a464

The let interpolated = interpolated_line.clone() allocation was redundant — just renamed the binding to interpolated directly. The handle_line path already did this correctly; exec_lines now matches.

N2 — Double interpolation in run_dumb_loop path — Confidence: 8/10

run_dumb_loop now pre-interpolates at line 4686, then passes the result to handle_backslash_dumb, which calls settings.vars.interpolate(input) again internally. For the postgres_dba case this is harmless (expanded value \i start.psql has no :varname tokens). But in theory: \set a ':b' then \set b 'hello' — first interpolation of :a yields :b, second yields hello. psql only interpolates once. This is a pre-existing quirk in handle_backslash_dumb (it always re-interpolated its input), now slightly more exposed because the dumb loop path changed from single to double interpolation. Suggest a follow-up to have handle_backslash_dumb accept already-interpolated input.

Suggestions

S1 — :varname expanding to / commands is not handled — Confidence: 6/10

In handle_line, the / (AI command) dispatch happens on the raw trimmed line before interpolation. So \set ask '/ask what indexes?' + :ask would fall through to SQL instead of dispatching as an AI command. Pre-existing issue, not introduced here — but worth a follow-up issue since this PR establishes the interpolate-first pattern.

S2 — Test coverage gaps — Confidence: 7/10

The expect script validates the interactive readline path only. Not covered:

• :varname not set (should fall through to SQL, not crash)
• run_dumb_loop path: echo ':dba' | rpg ...
• exec_lines path: a .psql file containing :dba

These are fine as follow-up issues — the happy-path GIF demo is solid evidence for the primary fix.

Summary

Correct fix for a real psql compatibility bug. Interpolate-before-dispatch applied consistently across all three input paths. N1 cleaned up. N2 is a pre-existing quirk, not a regression. Ready to merge.

Sprint check — ready for merge

CI: green (latest run all checks passed)

REV: APPROVE — no blocking findings. Non-blocking notes:

• N1 (unnecessary .clone()) — already fixed in follow-up commit a35a464
• N2 (double interpolation in run_dumb_loop) — pre-existing quirk, not a regression
• S1/S2 — follow-up suggestions, not blockers

Evidence: demos/postgres-dba.cast + demos/postgres-dba.gif committed in the diff. The expect script at tests/ai/postgres-dba.exp covers the primary fix path (interactive readline) end-to-end.

No merge without Nik approval.