Add a differential check, and fix the plxgo Sprintf bug it found

[jdatcmd]

Why

The regression suite records what each dialect produces. It cannot say whether what it produces is right, because the expected output was written by reading the same transpiler that is under test. A front end can be confidently, consistently wrong and the goldens will agree with it.

The check

test/differential.py (make differentialcheck) supplies the missing oracle. Each case is one small program written once as a plpgsql reference and once per dialect, then called with the same arguments. The reference is the plpgsql a PostgreSQL developer would have written for the same logic, so a disagreement between a dialect and the reference is a defect rather than a difference of opinion.

• Values compared by text form, with NULL distinguished from the empty string.
• A case that raises must raise the same SQLSTATE, so error parity is covered too.
• Intended divergences are recorded per case with the dialects, calls, and reason, and reported rather than failed.
• The check fails if a recorded divergence stops happening, so a documented limitation cannot quietly outlive the documentation describing it.
• Dialects a case cannot cover are printed, not silently skipped.

Eight cases, 388 comparisons: 374 agree with the reference, 14 are the documented NULL-interpolation behaviour, 0 unexplained.

The bug it found

In expression position fmt.Sprintf passed its Go format string straight into SQL format(), which understands only %s, %I, %L and %%. Every other verb raised unrecognized format() type specifier when the function was called:

CREATE FUNCTION f(nm text, n int) RETURNS text LANGUAGE plxgo AS $$
	return fmt.Sprintf("user %s has %d items", nm, n)
$$;
SELECT f('bob', 3);
-- ERROR:  unrecognized format() type specifier "d"

The transpile succeeded and the failure only appeared at run time, so fmt.Sprintf("%d", n), the ordinary way to format an integer in Go, produced a function that could not run. Go's verbs are now rewritten to the %s that format() understands, keeping a - flag and a width and dropping the flags and precision format() has no equivalent for. doc/plxgo.md had described only the RAISE statement path and is corrected; the dropped precision is recorded in doc/LIMITATIONS.md.

Verification

On PostgreSQL 18.4: clean build with no warnings, 13/13 installcheck, differentialcheck clean. The check itself was verified to catch an injected boundary defect (>= changed to >) and a stale exemption, and to exit non-zero when it does.

🤖 Generated with Claude Code

[jdatcmd]

Adversarial review

Reviewed against the change's own stated intent rather than for style. Three defects, all now fixed in b3affbf.

1. The fix did not fully do what it claimed. The stated goal was that fmt.Sprintf should stop producing functions that fail when called. But a % that starts no directive was passed straight through, and a lone % is itself an error to format():

CREATE FUNCTION a1() RETURNS text LANGUAGE plxgo AS $$
	return fmt.Sprintf("100%")
$$;
SELECT a1();
-- ERROR:  unterminated format() type specifier

Not a regression (it failed before too), but the same class of run-time failure the commit set out to remove, and the code comment said "leave the '%' alone" as if that were safe. Now escaped to %%, so it reaches the caller as a literal percent.

2. The documentation understated the cost. Saying only that flags and precision are dropped implies the difference is padding. It is not, for the verbs that change an operand's representation:

SELECT g_sprintf_repr(255);  -- fmt.Sprintf("%x|%o|%b|%q", n, n, n, n)
--  255|255|255|255

%x of 255 gives 255, not ff. That is a wrong value, not a wrong width, and it is silent, which is worse than an error for someone migrating Go code. Both doc/plxgo.md and doc/LIMITATIONS.md now say so explicitly and point at an explicit conversion.

3. The differential probe could silently mis-map results. One probe was assumed to be one output line. A value containing a newline, or a blank value dropped by the runner's if ln != "" filter, shifts every later result onto the wrong probe. The length check usually catches it, but a two-line value and a blank value in the same run cancel out and the mis-mapping goes unnoticed. The probe now returns a sentinel for the empty string and escapes newlines, and the runner no longer discards blank lines.

Regression cases added for all three.

Verification

PostgreSQL 18.4: clean build with no warnings, 13/13 installcheck, differentialcheck at 374 matching / 14 documented / 0 unexplained. Re-confirmed after the probe change that the check still exits 1 on an injected >=/> boundary defect, since that edit touched the result-parsing path.

🤖 Generated with Claude Code