Pql, un lenguaje de consultas en canalización que compila a SQL

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo lenguaje de consultas en canalización llamado Pql, inspirado en herramientas como Kusto y el SPL de Splunk, busca ofrecer una alternativa más legible y centrada en seguridad frente a SQL, compilando aun así a SQL estándar para su ejecución. Los comentaristas debaten si esta abstracción adicional aporta beneficios reales frente a opciones maduras como PRQL, bibliotecas al estilo LINQ o simplemente escribir SQL directamente, y plantean preocupaciones sobre el rendimiento, las funciones que faltan (por ejemplo, funciones de ventana) y el coste a largo plazo de mantener otro DSL más. Otros argumentan que la complejidad de SQL, sus dialectos inconsistentes y el manejo torpe de conceptos como null justifican experimentos como Pql, especialmente si se integran limpiamente con las bases de datos y herramientas existentes.

Motivación y usuarios objetivo

  • Diseñado como un lenguaje pequeño, en canalización, que compila a SQL, fuertemente inspirado en lenguajes de consulta al estilo Kusto / SPL.
  • Orientado especialmente a ingenieros y analistas de seguridad a quienes no les gusta SQL y que ya están acostumbrados a KQL, Splunk SPL, Sumo, etc.
  • Se lo ve como una forma de obtener una ergonomía similar a KQL sobre motores SQL generales y reducir la dependencia de proveedores frente a DSLs propietarios de consulta de logs.

Comparación con SQL

  • A los defensores les gusta el estilo lineal, de izquierda a derecha, en canalización, y la sintaxis más corta, similar a KQL.
  • Los críticos sostienen que los ejemplos comparan un Pql “bonito” con SQL deliberadamente enrevesado; un SQL idiomático podría ser casi igual de simple.
  • Algunos argumentan que la estabilidad y ubicuidad de SQL pesan más que los beneficios de aprender otro DSL; otros ven SQL como algo fundamentalmente torpe o “terrible”.

Relación con otros lenguajes de consulta (PRQL, LINQ, etc.)

  • Comparaciones fuertes con PRQL: ambos compilan a SQL con sintaxis de canalización.
  • Se pregunta por qué no reutilizar PRQL; las respuestas citan una audiencia distinta, preferencias de sintaxis y el deseo de una implementación pura en Go.
  • También se compara con LINQ, dbplyr, CoffeeScript/TypeScript sobre JS y múltiples proyectos similares de “post-SQL” (TQL, XTQL, Preql).

Rendimiento y planificación de consultas

  • Preocupa que la salida de Pql, muy cargada de CTE (subconsultas WITH), pueda ser lenta o forzar malos órdenes de join.
  • Otros señalan que los motores modernos a menudo inlinéan los CTE, así que los casos simples no deberían ser un problema; pero el impacto en consultas complejas no está claro.
  • Escepticismo general sobre que otra capa de abstracción pueda ser “más eficiente” que escribir SQL directamente, aparte de la productividad del desarrollador.

Opciones de implementación (Go, bindings, parsing)

  • Debate sobre usar Go frente a envolver PRQL basado en Rust: Go + bindings C funcionan, pero algunos ven la FFI de Go como torpe; otros dicen que la sobrecarga hoy es menor.
  • El autor escribió un parser a mano; otros comentaristas comparten experiencias de construir parsers de descenso recursivo como algo educativo y flexible.

Manejo de null y semántica

  • Pql hereda el comportamiento de NULL de SQL ya que solo transpila; no corrige los problemas de la lógica de tres valores.
  • Algunos sostienen que un mejor diseño usaría tipos Option/Maybe, pero eso requeriría un lenguaje fundamentalmente distinto, no solo un frontend de SQL.

LLMs vs DSLs

  • Varios señalan que las herramientas de LLM a SQL son prometedoras pero poco fiables: sirven para borradores iniciales, no para consultas críticas en cuanto a corrección.
  • Algunos presentan Pql como un puente más determinista: más fácil que SQL para ciertos usuarios, pero aún explícito y verificable.

Limitaciones y escepticismo

  • Los comentaristas señalan la ausencia de funciones SQL avanzadas (funciones de ventana, filtrado de agregados, funciones específicas de tipos de datos, parámetros).
  • Algunos temen una complejidad añadida, una segunda capa “bajo el capó” sobre el planificador de consultas, y otro lenguaje de consulta efímero más.
  • Otros están entusiasmados con la ergonomía similar a KQL sobre backends SQL estándar y स्वागतan más experimentación en este espacio.