From e668a9ddacd6cd44c5b8d5046637edf4ee5dfe05 Mon Sep 17 00:00:00 2001
From: Rene Cannao <rene@proxysql.com>
Date: Fri, 22 May 2026 16:16:46 +0000
Subject: [PATCH] fix(test): update pgsql digest fixtures for typecast
 trailing-space behavior
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

PR #5755 (commit e6bef5c58) 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.
---
 .../pgsql_regular_tokenizer_digests.hjson            | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/test/tap/tests/tokenizer_payloads/pgsql_regular_tokenizer_digests.hjson b/test/tap/tests/tokenizer_payloads/pgsql_regular_tokenizer_digests.hjson
index e7e576484..87250e5df 100644
--- a/test/tap/tests/tokenizer_payloads/pgsql_regular_tokenizer_digests.hjson
+++ b/test/tap/tests/tokenizer_payloads/pgsql_regular_tokenizer_digests.hjson
@@ -278,7 +278,7 @@
 			"select '{\"key\":\"value\"}'::json -> 'key'",
 			"select '[1,2,3]'::json -> 1"
 		],
-		"s1": "select ?-> ?",
+		"s1": "select ? -> ?",
 		"s2": "select ?-> ?",
 		"s3": "select ?-> ?",
 		"s4": "select ?-> ?"
@@ -288,10 +288,10 @@
 		"q": [
 			"select '{\"key\":\"value\"}'::jsonb @> '{\"key\":\"value\"}'"
 		],
-		"s1": "select ?@> ?",
-		"s2": "select ?@> ?",
-		"s3": "select ?@> ?",
-		"s4": "select ?@> ?"
+		"s1": "select ? @> ?",
+		"s2": "select ? @> ?",
+		"s3": "select ? @> ?",
+		"s4": "select ? @> ?"
 	},
 	// ========================
 	// SECTION 8: DOLLAR PARAMETERS
@@ -656,7 +656,7 @@
 			"select '$1,000.00'::money + '$12.34'::money",
 			"select '12.34'::money + '5.66'::money"
 		],
-		"s1": "select ?+ ?",
+		"s1": "select ? + ?",
 		"s2": "select ?+?",
 		"s3": "select ?+?",
 		"s4": "select ?+?"