plx : Write PostgreSQL functions in the language you already know.

What plx is plx is a PostgreSQL extension that lets you write stored functions and triggers in the dialect you already know (the current set is listed below).

When you run CREATE FUNCTION, plx transpiles the body to plpgsql and stores that plpgsql in pg_proc.prosrc. At run time the function is executed by PostgreSQL's own plpgsql interpreter.

There is no separate language runtime loaded into the backend, and nothing new to run in production. The front end is dialect-pluggable, and the set of dialects is growing.

The dialects available today are: plxruby: a Ruby dialect. plxphp: a PHP dialect. plxjs: a JavaScript dialect. plxpython3: a Python dialect. plxcobol: a COBOL dialect (ISO/IEC 1989:2023). plxplsql: an Oracle PL/SQL dialect. plxts: a TypeScript dialect (plxjs plus type annotations). plxtsql: a Transact-SQL (SQL Server) dialect. plxgo: a Go dialect. Every plpgsql statement type is reachable from every dialect.

See doc/PARITY.md for the construct matrix. The language names carry a plx prefix, so the extension coexists with the native PL/Ruby and PL/PHP languages in the same database. Why it exists PostgreSQL rewards moving logic into the database: triggers, constraints, set-returning functions, and cursors all run closest to the data.

The standard way to write that logic is plpgsql. plpgsql is fast and trusted, but its syntax is unfamiliar to developers who spend their day in Ruby, PHP, JavaScript, or Python, and that unfamiliarity is often enough to keep logic in the application tier where it does not belong. The usual alternative is an untrusted procedural language such as plpython3u or plperlu.

Those give you a familiar syntax, but at a cost: they load a full language interpreter into the backend, most are untrusted and therefore superuser-only, and every row they touch is marshalled across an SPI boundary into the interpreter's own data structures. plx takes a different position.

A new language surface does not require a new execution engine. plx changes only the syntax you write, not what runs: It is still plpgsql. The stored function body is plpgsql, executed by the plpgsql handler. You get plpgsql's performance and its safety as a trusted language, with no interpreter loaded into the backend.

Nothing is hidden. The generated plpgsql is stored in pg_proc.prosrc, where you can read exactly what will run. plx embeds the original source as a comment so the function is idempotent to re-transpile, but the executable body is ordinary plpgsql you can inspect, pg_dump, and review. The cost is paid once. Translation happens at CREATE FUNCTION time, not per call.

At run time there is no translation layer and no per-row marshalling beyond what plpgsql already does. The goal is to meet developers where they are on syntax without changing what the database actually executes. Who it is for Application developers who want to push logic into the database using syntax they already know, rather than learning plpgsql first.

Teams standardizing on PostgreSQL who want triggers and functions written in a familiar dialect but running with plpgsql's performance and trust model. Anyone who wants the generated plpgsql to be visible and reviewable rather than executed by an opaque runtime.