¿Qué es plx?

plx es una extensión de PostgreSQL que permite escribir funciones almacenadas y triggers utilizando un dialecto de programación que ya conoces (el conjunto actual se indica a continuación). Al ejecutar CREATE FUNCTION, plx transpila el cuerpo de la función a plpgsql y guarda el código resultante en pg_proc.prosrc. Cuando la función se ejecuta, PostgreSQL utiliza su propio intérprete de plpgsql. Esto significa que no es necesario cargar un runtime de lenguaje adicional en el backend ni incorporar ningún componente nuevo al entorno de producción.

El front end admite distintos dialectos mediante un sistema de plugins, y el conjunto de dialectos continúa creciendo. Los dialectos disponibles actualmente son:

• plxruby: un dialecto de Ruby. 
• plxphp: un dialecto de PHP. 
• plxjs: un dialecto de JavaScript. 
• plxpython3: un dialecto de Python. 
• plxcobol: un dialecto de COBOL (ISO/IEC 1989:2023). 
• plxplsql: un dialecto de Oracle PL/SQL. 
• plxts: un dialecto de TypeScript (plxjs con anotaciones de tipos). 
• plxtsql: un dialecto de Transact-SQL (SQL Server). 
• plxgo: un dialecto de Go. 

Cualquier dialecto puede acceder a todos los tipos de sentencias de plpgsql. Para consultar la matriz de construcciones, véase doc/PARITY.md. Los nombres de los lenguajes incorporan el prefijo plx, de modo que la extensión puede coexistir en una misma base de datos con los lenguajes nativos PL/Ruby y PL/PHP.

Por qué existe

PostgreSQL ofrece ventajas cuando la lógica se ejecuta dentro de la propia base de datos: los triggers, las restricciones, las funciones que retornan conjuntos y los cursores se ejecutan directamente junto a los datos. La forma habitual de implementar esta lógica es mediante plpgsql. Aunque plpgsql es rápido y ampliamente probado, su sintaxis puede resultar poco familiar para desarrolladores acostumbrados a trabajar a diario con Ruby, PHP, JavaScript o Python. Esa falta de familiaridad hace que, con frecuencia, la lógica permanezca en la capa de aplicación, donde no debería estar.

La alternativa habitual es utilizar un lenguaje procedural no confiable, como plpython3u o plperlu. Estos lenguajes proporcionan una sintaxis conocida, pero tienen un coste: cargan un intérprete completo dentro del backend, la mayoría son lenguajes no confiables y, por ello, solo pueden ser utilizados por un superusuario. Además, cada registro que procesan debe pasar por la frontera SPI y convertirse a las estructuras de datos propias del intérprete.

plx adopta un enfoque distinto. Incorporar una nueva forma de escribir el código no implica necesariamente añadir un nuevo motor de ejecución. plx modifica exclusivamente la sintaxis con la que se escribe el código, no el mecanismo mediante el cual este se ejecuta:

• Sigue siendo plpgsql. El cuerpo de la función almacenada está escrito en plpgsql y lo ejecuta el manejador de plpgsql. De este modo, se obtiene el rendimiento de plpgsql y la seguridad que ofrece como lenguaje de confianza, sin necesidad de cargar un intérprete en el backend.
• No hay nada oculto. El código plpgsql generado se almacena en pg_proc.prosrc, lo que permite consultar directamente y con precisión el código que será ejecutado. plx incorpora el código fuente original como un comentario, de modo que la función puede volver a transpilarse de manera idempotente. No obstante, el cuerpo ejecutable es plpgsql convencional, susceptible de ser inspeccionado, incluido en un pg_dump y sometido a revisión. 
• El coste se asume una sola vez. La traducción se lleva a cabo al ejecutar CREATE FUNCTION, no cada vez que se invoca la función. Durante la ejecución no existe ninguna capa de traducción ni un procesamiento adicional de los datos por registro más allá de lo que ya hace plpgsql.

El objetivo es ofrecer a los desarrolladores una sintaxis familiar, sin modificar lo que la base de datos ejecuta realmente.

Para quién es

• Desarrolladores de aplicaciones que quieren trasladar la lógica a la base de datos utilizando una sintaxis que ya conocen, en lugar de tener que aprender primero plpgsql.
• Equipos que están estandarizando el uso de PostgreSQL y quieren triggers y funciones escritos en un dialecto familiar, pero ejecutándose con el rendimiento y el modelo de confianza de plpgsql.
• A quienes prefieren que el código plpgsql generado sea visible y pueda revisarse, en lugar de depender de un runtime cuyo funcionamiento interno no resulta transparente.