Skip to content

[2.1.0] Don't fold interpolated initializers into DECLARE; reject constants that read locals - #21

Open
OffgridwithJD wants to merge 1 commit into
commandprompt:masterfrom
OffgridwithJD:fix/declare-fold-order
Open

OffgridwithJD wants to merge 1 commit into
commandprompt:masterfrom
OffgridwithJD:fix/declare-fold-order

Conversation

@OffgridwithJD

Copy link
Copy Markdown

Summary

Two silent miscompiles. In both, generated code computes a value at function start that the source computes later. The plxcsharp review found the first one.

An interpolated string as a local's first value read stale values

A local's first top-level assignment of a string literal is folded into DECLARE as its initializer. That initializer runs when the function starts. An interpolating string was folded too, so it read its variables before the statements above it had run:

v = "v0"
v = "v2"
s = "got #{v}"
return s          # returned "got v0"
DECLARE
  v text := 'v0';
  s text := 'got ' || (v)::text;   -- runs at entry
BEGIN
  v := 'v2';
  RETURN s;

This affected plxjs (`${v}`), plxpython3 (f"{v}"), plxruby ("#{v}") and plxphp ("$v"). Calls made inside an interpolation also ran early, before any statements above them. Such an assignment now runs in place. A plain literal is still folded.

A constant computed from a local read its initial value

A constant becomes a plpgsql CONSTANT, which is also computed at function start. So v = 1; v = 2; c = v + 1 #:: int const gave c = 2. A constant may now use only literals, parameters and earlier constants. Reading another local is rejected at CREATE FUNCTION:

ERROR:  plxruby: constant "c" cannot use local variable "v": a constant's value is computed when the function starts

The check scans the constant's generated SQL. It skips string literals, quoted identifiers, field names after . and type names after ::, and reports the first non-constant local it finds. The per-dialect chapters now document the rule.

Compatibility

Code-only, so no ALTER EXTENSION is needed.

  • A function whose first assignment interpolates now behaves as its source says.
  • A constant that reads a non-constant local was already wrong, and is now an error.

Testing

  • make installcheck: all 13 suites pass on PG 18.4. CI covers 13 to 18.
  • make differentialcheck: 0 unexplained.
  • New cases:
    • plx_features: the four dialects return got v2; a constant built from a parameter and an earlier constant still folds, and so does a plain literal (listing shown).
    • plx_errors: a constant that reads a local, in plxruby and plxjs, is rejected.

🤖 Generated with Claude Code

…hat read locals

A local's first top-level assignment of a string literal is folded into
DECLARE as its initializer, which runs when the function starts. An
interpolating string was folded too, so it read its variables before the
statements above it ran: in plxjs, plxpython3, plxruby and plxphp,
'v = "v0"; v = "v2"; s = "got #{v}"' returned "got v0". Such an assignment
now runs in place; a plain literal is still folded.

A constant has the same timing by design (plpgsql CONSTANT), so a constant
computed from a local read the local's initial value. A constant's
initializer may now use only literals, parameters and earlier constants;
reading another local is rejected with an explanation.

Reported by the plxcsharp front end's review, which worked around the
first case by parenthesizing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants