fix(test): update pgsql digest fixtures for typecast trailing-space behavior#5804
fix(test): update pgsql digest fixtures for typecast trailing-space behavior#5804renecannao wants to merge 2 commits into
Conversation
…ehavior PR #5755 (commit e6bef5c) fixed `process_pg_typecast()` in `lib/pgsql_tokenizer.cpp` so that the trailing space after a PG typecast is preserved unless the next non-space character is a modifier `(` or array bracket `[`. The commit message documented this as an intentional behaviour change: "The new lookahead-conditional skip preserves the trailing space unless the very next non-space character is a modifier `(` or array bracket `[`." Three test cases in `tokenizer_payloads/pgsql_regular_tokenizer_digests.hjson` hardcoded expected digests against the OLD (buggy) tokenizer output, where the space-eating bug glued the preceding literal to the following operator. With the fix in place those expectations mismatch, making `pgsql-query_digests_stages_test-t` fail deterministically in the legacy-g4 TAP group on v3.0 HEAD: * `::json -> 'key'` STAGE 1: actual `select ? -> ?` vs old expected `select ?-> ?` * `::jsonb @> ...` STAGE 1-4: actual `select ? @> ?` vs old expected `select ?@> ?` * `::money + ...` STAGE 1: actual `select ? + ?` vs old expected `select ?+ ?` For `->` and `+`, only STAGE 1 changes — STAGE 2-4's existing whitespace-collapse step still glues `?->` and `?+` for those operators, so `s2`/`s3`/`s4` expectations stay as-is. For `@>`, none of the stages collapse the space, so all four expectations move. The new actual digest output is the more correct one — it mirrors the existing MySQL tokenizer's behaviour for the same shape, where `'literal' + 'literal'` already produces `? + ?` at STAGE 1. This commit only updates the fixture; no tokenizer or test source changes. Verified locally against the existing test binary (built from v3.0 HEAD, includes the new tokenizer behaviour): ./pgsql-query_digests_stages_test-t → 734/734 ok, RC=0 The 9 previously-failing assertions (#381, #385, #389-#392, #592, #596, #600) all flip to ok with the updated fixture.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📜 Recent review details⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (1)
📝 WalkthroughWalkthroughThis PR updates PostgreSQL tokenizer test fixture expectations to reflect consistent operator spacing. Three operator cases are updated: JSON ChangesOperator Spacing Test Updates
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the expected tokenizer digests in pgsql_regular_tokenizer_digests.hjson by adding spaces around various SQL operators, such as ->, @>, and +, in the test payloads. I have no feedback to provide as there were no review comments.
|



Summary
Updates 3 expected-digest test cases in
tokenizer_payloads/pgsql_regular_tokenizer_digests.hjsonto match the corrected tokenizer behavior introduced by PR #5755 (commite6bef5c58), which intentionally preserves the trailing space after a PG typecast unless the next non-space char is a modifier(or array bracket[.Before this fix,
pgsql-query_digests_stages_test-tfails deterministically in thelegacy-g4TAP group on v3.0 HEAD with 9 not-ok assertions across::json ->,::jsonb @>, and::money +shapes.Failures fixed
select '...'::json -> 'key'select ? -> ?select ?-> ?select '...'::jsonb @> '...'select ? @> ?select ?@> ?select '...'::money + '...'::moneyselect ? + ?select ?+ ?For
->and+, only STAGE 1 changes — STAGE 2-4's whitespace-collapse step still glues?->and?+for those operators. For@>, none of the stages collapse the space, so all four expectations move.Test plan
./pgsql-query_digests_stages_test-t→ 734/734 ok, RC=0 (was 725/734 with 9 not-ok)Summary by CodeRabbit