The plx extension for PostgreSQL lets you write stored functions and triggers in a familiar programming language, then transpiles them to plpgsql at CREATE FUNCTION time. The generated code is stored in pg_proc.prosrc and executed by PostgreSQL's own plpgsql interpreter—no separate language runtime is loaded into the backend. This approach keeps production deployments simple, as nothing new needs to be installed or maintained at runtime.
The extension's front end is dialect-pluggable, and the current set of dialects includes:
- 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 any dialect, as documented in doc/PARITY.md. The language names carry a plx prefix, so the extension coexists with native PL/Ruby or PL/PHP languages in the same database without conflicts.
Why it matters: The project aims to remove a major barrier to moving logic into the database—the need to learn plpgsql. By letting developers write database functions in languages they already use, plx encourages adoption of database-centric patterns like triggers and constraints, which improve data integrity and performance. The dialect-pluggable architecture ensures future languages can be added easily. For teams considering PostgreSQL, plx lowers the learning curve and enables more expressive server-side logic, while keeping the execution environment lean and secure.