plx
Overview
| ID | Extension | Bin | Lib | Load | Create | Trust | Reloc | Schema |
|---|---|---|---|---|---|---|---|---|
| 3140 | plx | No | Yes | No | Yes | No | Yes | - |
| Related | plpgsql plisql plpgsql_wrap orafce db2fce |
|---|
Uses PostgreSQL’s built-in PL/pgSQL call handler; no control-file dependency is declared.
Version
| Type | Repo | Version | PG Ver | Package | Deps |
|---|---|---|---|---|---|
| EXT | PIGSTY | 1.3.1 | 1817161514 | plx | - |
| RPM | PIGSTY | 1.3.1 | 1817161514 | plx_$v | - |
| DEB | PIGSTY | 1.3.1 | 1817161514 | postgresql-$v-plx | - |
Build
You can build the RPM / DEB packages for plx using pig build:
Install
You can install plx directly. First, make sure the PGDG and PIGSTY repositories are added and enabled:
Install the extension using pig or apt/yum/dnf:
Create Extension:
Usage
Sources:
plx provides familiar procedural-language dialects that transpile to ordinary PL/pgSQL when CREATE FUNCTION runs. PostgreSQL stores and executes the generated PL/pgSQL with its built-in trusted handler; no Ruby, PHP, JavaScript, Python, Go, COBOL, Oracle, or SQL Server runtime is loaded into the backend.
Available Dialects
| Language | Surface syntax |
|---|---|
plxruby | Ruby |
plxphp | PHP |
plxjs | JavaScript |
plxts | TypeScript annotations over the JavaScript dialect |
plxpython3 | Python 3 |
plxgo | Go |
plxcobol | ISO COBOL |
plxplsql | Oracle PL/SQL |
plxtsql | Transact-SQL |
All dialects target the same PL/pgSQL statement surface, including assignments, conditionals, loops, query iteration, dynamic SQL, cursors, exceptions, triggers, and set-returning functions.
Create a Function
Choose a dialect in the LANGUAGE clause while keeping the function signature in PostgreSQL types:
Translation happens once, when the function is created. The executable body stored in pg_proc.prosrc is regular PL/pgSQL, so it can be dumped, reviewed, and run without a separate interpreter.
Inspect and Debug Generated Code
Runtime error line numbers refer to generated PL/pgSQL. plx_source() recovers the original embedded dialect body; use it together with pg_get_functiondef() when correlating an error with the source.
SQL and String Building
Expressions retain PostgreSQL SQL semantics rather than emulating a complete source-language runtime. Use each dialect’s query/execute form for SQL and explicit PostgreSQL types for non-literal expressions. The plx_strbuild expanded-object helper accelerates repeated string appends on PostgreSQL 18:
The builder remains correct on PostgreSQL 13-17, but its in-place optimization requires PostgreSQL 18.
Boundaries and Caveats
- plx implements syntax surfaces, not the source languages’ runtimes: there are no gems, Python modules, JavaScript imports, Go goroutines, PHP classes, Oracle packages, or SQL Server transaction commands.
- Functions run in PL/pgSQL’s trusted sandbox, with no direct filesystem, network, arbitrary native-code, or transaction-control access.
- Parameters and return types must be PostgreSQL types. Type inference for locals is limited; explicitly declare types for calls and compound expressions.
- SQL uses three-valued logic and PostgreSQL numeric/string semantics. Source-language truthiness and string concatenation with
+are not reproduced. - Locals are hoisted into one PL/pgSQL
DECLAREblock, so block-local scope and redeclaration with a different type are unavailable. - Version 1.3.1 is a code-only safety release: it adds lexer/string-builder capacity guards, stack-depth checks, bounded indentation handling, and fixes for raw-string, PHP interpolation, and non-decimal integer literal parsing. After installing the binary, run
ALTER EXTENSION plx UPDATE TO '1.3.1'.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)