[OffgridwithJD]

Summary

Fixes from a security audit of the transpiler. Every plx language is TRUSTED, so by default any role can send arbitrary input to this C code through CREATE FUNCTION or DO. Each issue below was reproduced against PostgreSQL 18.4 before fixing, and each fix has a regression test.

Code-only: no SQL objects change, so this needs no ALTER EXTENSION.

Backend crashes (any role, including from a DO block)

These kill the backend with SIGSEGV, so the postmaster resets every session on the server.

• Type annotation at the start of a span. /*:: T */ or #:: T as the first token of a condition, call argument or statement made plx_span_text copy from a NULL pointer. Affected plxjs, plxts, plxphp, plxruby and plxpython3. Repro: DO LANGUAGE plxjs $q$ assert(/*:: int */ 1 > 0); $q$;
• Unbounded recursion in the plxtsql, plxgo and plxcobol expression emitters. ISNULL(ISNULL(...)) or int(int(...)) about 50,000 levels deep overflowed the C stack. These emitters now use check_stack_depth() plus the PLX_MAX_DEPTH counter, matching the shared rewriter.

Generated code that does not match its source

• String literal escaping its quotes. A string ending in a lone backslash inside an interpolation (plxjs/plxts template, plxpython3 f-string) was emitted bare inside E'...', where it escaped the closing quote. The next string literal's text then ran as code. Source that shows only inert assignments could therefore run set_config(...) or any other SQL, which matters for SECURITY DEFINER functions and for code review.
• Literals that depend on standard_conforming_strings (found in review). Literals emitted by plxgo, plxtsql, plxplsql and plxcobol, and Ruby/PHP single-quoted strings, were plain '...'. plpgsql reads the body with the caller's setting, so with it off a trailing backslash swallowed the closing quote and the next literal ran as code. A final pass over the generated body now rewrites every ordinary literal containing a backslash as E'...' with the backslash doubled. That reads the same under either setting and keeps the value with it on. It covers every dialect and SQL passed through verbatim.
• plxgo fmt.Sprintf directive without a letter verb. %' consumed half of an escaped '', so Go string text could become SQL. Such directives now fall back to the format() lowering.

Resource exhaustion (memory / CPU, uninterruptible)

Input	Before	After
finally nested in finally, 16 levels (668 B source)	94 MB prosrc; 24 levels drove a backend to 2.3 GB	capped at 8 levels, with a clean error. This bounds depth, not size: at the cap the output can still be about 2^8 × the source (a 195 KB body stores about 144 MB). #16 removes the doubling.
1 MB chain of 490 ternaries	568 MB peak	87 MB peak
40,000 distinct locals	47 s, ignored statement_timeout	0.1 s, including after an over-long name (keys are downcase_truncate_identifier)
plxpython3 body with 400,000 blank lines	43 s, ignored statement_timeout	8 ms; 40,000 #:: lines take 0.02 s

• Locals are now hashed.
• The Python lexer scans each run of blank lines once. This also fixes doubled line numbers in its error messages.
• Ternary intermediates are freed.
• CHECK_FOR_INTERRUPTS() now runs in the lexer, the rewriter and the local table.
• The three copies of the try/finally lowering are now one helper, plx_emit_try.

Behaviour fixes that fell out of the above

• A finally/ensure body that raised on the normal path ran a second time from the error path. It now runs once.
• plxpython3 call(f"...") emitted an unterminated identifier. It is now rejected.

Not in this PR (need a design decision)

• USAGE on a plx language means you can run plpgsql. A body that already starts with the /*plx:v1: header is stored without transpiling. Even without that, the plx languages are a syntax layer over plpgsql. After REVOKE USAGE ON LANGUAGE plpgsql FROM PUBLIC, DO LANGUAGE plxplsql still works. This is documented in the docs PR; a code-level check is a separate decision.
• Interpolation in dynamic SQL is not quoted. execute("... #{x}"), and fetch_one/query once a bind argument is added, concatenate the value without quoting, so data can inject SQL. This is documented as the author's responsibility, but the inconsistency is a trap.
• Unqualified plx_strbuild / plx_sb_append in generated code. They resolve through search_path at run time, which matters for SECURITY DEFINER. The extension is relocatable, so this can't be schema-qualified without changing that.
• finally doesn't run on return/break/continue. Fixing it requires emitting the body once.

Review follow-up

Addressed in 2717c2f:

• the standard_conforming_strings breakout (above)
• the annotation-line bypass of the lexer fix
• the long-name bypass of the locals hash, and the case-folding mismatch
• the finally-cap wording
• tests:
  • standard_conforming_strings off across six dialects
  • timeout-bounded tests for the three slow cases
  • a nesting test under the 500-level counter with max_stack_depth = 100kB, so check_stack_depth() itself is exercised

Not covered by a test: the ternary memory fix. Its effect is peak memory, which pg_regress can't measure.

Testing

• make installcheck: all 13 suites pass on PG 18.4. CI covers 13 to 18.
• make differentialcheck passes.
• test/fuzz.py (500 iterations): no crashes.
• Annotation-position fuzz (456 inputs across 5 dialects): no crashes.

🤖 Generated with Claude Code

[jdatcmd]

Adversarial review. Tested on PostgreSQL 18.4: built this branch and ran make installcheck (13/13 pass, no compiler warnings). The new plxjs annotation test, run against a master build, crashes the backend, so it does reproduce the bug.

CI has not run on this PR yet (fork run waiting for approval), so PostgreSQL 13 to 17 are untested. That matters here because the hash_create call is version-dependent.

Must fix

1. The string-literal breakout is still open

The PR and CHANGELOG say "Literal backslashes are now always escaped". That is not true. These are still emitted as plain '...' literals with a bare backslash:

• Ruby and PHP single-quoted (raw) strings
• plxgo strings
• plxtsql strings

plpgsql reads a function body with the session's standard_conforming_strings, which any role can set. With it off, the backslash escapes the closing quote. Repro:

CREATE FUNCTION go1() RETURNS text LANGUAGE plxgo AS $P$
a := "C:\\"
b := "; RAISE NOTICE $$go: injected code ran$$; --"
return a
$P$;
SET standard_conforming_strings = off;
SELECT go1();
-- NOTICE:  go: injected code ran

plxtsql (DECLARE @a varchar(10) = 'C:\';), plxruby and plxphp (a = 'C:\\') break out of the quote the same way. The caller controls this setting, so it can change what a SECURITY DEFINER function does. The bug is older than this PR, but it is the class of bug this PR says it closes.

Suggested fix: in every emitter, whenever a literal contains a backslash, emit E'...' and double the backslash. That form does not depend on standard_conforming_strings. Add a regression test that sets the GUC off.

2. The lexer fix can be bypassed with annotation lines

A line starting with #:: sets held, but the scan still runs to the next real line from every newline. It is still quadratic:

body	time
x = 1 + 20,000 lines of #:: int	1.3 s
x = 1 + 40,000 lines of #:: int	5.1 s

3. The locals hash can be bypassed with one long name

A name of 128 or more characters destroys the hash for the rest of the body, which brings back the linear scan:

plxruby body	time
20,000 locals	52 ms
one 131-char name, then 10,000 locals	0.9 s
one 131-char name, then 20,000 locals	5.4 s

PostgreSQL truncates identifiers at 63 bytes anyway, so a key truncated to that length plus a collision chain (or a full-name compare on hit) avoids the fallback.

Findings 2 and 3 do respect statement_timeout now. Both stopped cleanly at 3 s, so they cost CPU time but cannot lock up a backend.

Should fix

4. The finally cap limits depth, not output size

At the 8-level cap, the expansion is about 740 times the source. A 195 KB plxjs body stores a 144 MB prosrc (1.4 s). The PR table reads as if this were bounded. Please either say in the PR and CHANGELOG that the output still scales at about 2^8 times the source, or add a cap on output size.

5. Test gaps

• No test covers the two quadratic fixes or the ternary memory fix. A coarse check would do, for example a body that took tens of seconds before, run under a short statement_timeout.
• The nesting tests use 2,000 levels, so they hit the 500-level counter and never exercise check_stack_depth().

Minor

• plx_local_key lower-cases with pg_ascii_tolower, but the fallback scan uses pg_strncasecmp, which also folds high-bit characters. In a single-byte encoding the two paths can disagree on whether two names match.

[OffgridwithJD]

Thanks for the review. Every point is addressed in 2717c2f.

Must fix

1. standard_conforming_strings: confirmed in plxgo, plxtsql, plxplsql and plxcobol, and in Ruby/PHP single-quoted strings. Fixed with one pass over the finished body, not per emitter. A small SQL lexer skips comments, quoted identifiers, dollar quotes, E'' and U&'' strings, and rewrites every ordinary literal containing a backslash to E'...' with the backslash doubled. That covers every dialect, future emitters, and SQL passed through verbatim. A new regression test sets the GUC off and calls six dialects.
2. Annotation lines: the blank-line scan now stops at a #:: line. 40,000 of them take 0.02 s.
3. Long-name bypass: the locals index is keyed by downcase_truncate_identifier(), as the server reads an unquoted identifier, so every name is indexed and the fallback is gone. A 131-character name followed by 20,000 locals takes 0.06 s. This also resolves the minor case-folding mismatch.

Should fix
4. Finally cap: the CHANGELOG and PR text now say it bounds depth, not size (about 2^8× at the cap). #16 removes the doubling.
5. Tests: timeout-bounded tests for the three slow cases (each over 20 s before the fix), and a nesting test under the 500-level counter with max_stack_depth = 100kB, which hits check_stack_depth() itself. The ternary fix has no test, because its effect is peak memory, which pg_regress can't measure.

#14 and #16 are rebased onto this.

[jdatcmd]

Re-review of 2717c2f on PostgreSQL 18.4. It builds without warnings, make installcheck passes 13/13 and make differentialcheck passes.

Fixed

Finding	Before	Now
Backslash breakout with standard_conforming_strings = off	injected code ran from plxgo	plxgo, plxtsql ('...' and N'...'), plxruby, plxphp and plxplsql '...' all become E'C:\\' and return C:\
#:: annotation lines	40,000 lines: 5.1 s	6 ms
Long name disabling the locals hash	long name + 20,000 locals: 5.4 s	35 ms
Tests for the above	none	added

The plxplsql check included an Oracle-style v$path identifier, which the new lexer correctly does not treat as a dollar quote.

Still open: N'...' literals in plxplsql

escape_backslash_literals skips any literal with a letter prefix (prefixed), so a national-character literal is left alone. Under standard_conforming_strings = off, an N'...' literal treats a backslash exactly like a plain '...' literal does. plxplsql passes Oracle N'...' literals through, and NVARCHAR2 code uses them routinely:

CREATE FUNCTION plsn2() RETURNS text LANGUAGE plxplsql AS $P$
DECLARE
  a NVARCHAR2(100);
  b NVARCHAR2(100);
BEGIN
  a := N'C:\';
  b := N'; RAISE NOTICE $$plsql N-string: injected code ran as %$$, current_user; --';
  RETURN a;
END;
$P$;
SET standard_conforming_strings = off;
SELECT plsn2();
-- NOTICE:  plsql N-string: injected code ran as postgres

(plxtsql is not affected: its emitter drops the N prefix.)

Suggested fix: treat an N or n prefix like no prefix, and rewrite N'C:\' as E'C:\\' (the national-character form only implies the type char, which the assigned variable's type overrides anyway), or keep it as N followed by an E-safe form. Add N'...' to the standard_conforming_strings test.

Checked and not a problem: a standalone #:: line before a dedented statement fails with unsupported statement, but master fails the same way.