plx Compatibility¶
Supported versions¶
plx supports PostgreSQL 13 through 18 (released), and builds and passes on the 19 and 20 development lines. The full pg_regress suite (plxruby, plxphp, plxjs, plxpython3, plxgo, plxcobol, plxplsql, plxts, plxtsql, and the rejection tests) passes on each of PostgreSQL 13 through 18, plus 19 and 20 built from source.
| PostgreSQL | Status | string builder |
|---|---|---|
| 13 | pass | correct, not accelerated |
| 14 | pass | correct, not accelerated |
| 15 | pass | correct, not accelerated |
| 16 | pass | correct, not accelerated |
| 17 | pass | correct, not accelerated |
| 18 | pass | accelerated (amortized O(1)) |
| 19 (beta) | pass (from source) | accelerated (amortized O(1)) |
| 20 (devel) | pass (from source) | accelerated (amortized O(1)) |
PostgreSQL 19 and 20 compile with a C23 toolchain (for example gcc 15), where
pg_noreturn becomes the standard [[noreturn]] attribute; plx writes it as the
first token of each declaration so it compiles across all of these versions.
The string builder is accelerated only on PostgreSQL 18¶
plx ships a string builder (plx_strbuild) and lowers the dialect string-append
operators onto it, so building a string in a loop is amortized O(1) instead of
the O(n^2) of s := s || 'x'. The in-place append relies on
SupportRequestModifyInPlace, which was introduced in PostgreSQL 18. On
PostgreSQL 13 to 17 the builder produces correct results, but the append is
O(n^2), the same as plain concatenation, because those versions only let the
built-in array functions take a read-write expanded argument. The transpiler
lowers to the builder on every version (the results are always correct); the
speedup appears when running on PostgreSQL 18. See the
benchmarks.
Why the version range holds¶
plx binds each dialect language to plpgsql's own call handler, so a plx function
executes as plpgsql. This depends on the plpgsql handler symbols
(plpgsql_call_handler, plpgsql_inline_handler) being resolvable from another
loaded module. On PostgreSQL 13 to 17 the server is built with default symbol
visibility, so these symbols are global. On PostgreSQL 18 they remain global
because they are the fmgr entry points (declared PGDLLEXPORT). The catalog
model plx uses (a language whose lanplcallfoid points at plpgsql's handler,
with the dialect body transpiled to plpgsql and stored in pg_proc.prosrc) is
unchanged across these versions.
Source portability¶
Two server APIs differ across the supported majors; plx handles both:
pg_noreturnis a PostgreSQL 18 prefix specifier. On earlier versions plx defines it as the compiler noreturn attribute.pg_b64_encodechanged signature across majors. plx uses a self-contained base64 encoder for the embedded original source, so it does not depend on the server function.
Reproducing¶
test/pg_matrix.sh builds PostgreSQL 13 to 17 from source, builds plx against
each pg_config, and runs the regression suite per version. Run it as root in a
build environment with the standard PostgreSQL build dependencies installed.