PRQL: lenguaje de consultas relacionales canalizado

 (github.com/PRQL)
4 puntos por GN⁺ 2023-07-27 | 1 comentarios | Compartir por WhatsApp
  • PRQL es un lenguaje moderno para transformar datos que apunta a ser un lenguaje alternativo a SQL, fácil de leer, explícito y declarativo, como SQL
  • Las consultas se componen como un pipeline lógico donde cada etapa de transformación toma el resultado anterior, y admite abstracciones como variables y funciones
  • PRQL compila a SQL para poder usarse con cualquier base de datos que utilice SQL
  • Los ejemplos del lenguaje usan transformaciones como from, filter, derive, group, aggregate, sort y take, y filter reemplaza el papel de WHERE y HAVING en SQL
  • Entre las funciones sintácticas ofrece notación clara de fechas, coalesce, variables que hacen referencia a otras variables, F-strings similares a Python, S-strings para usar SQL como escape hatch, notación de orden descendente y expresiones de rango
  • Ofrece PRQL Playground para experimentar en el navegador, PRQL Book como documentación del lenguaje, y prql-lang.org con comparaciones frente a SQL y ejemplos
  • A junio de 2026, puede usarse mediante integraciones compatibles o bindings de lenguaje compatibles, aunque todavía quedan algunos bugs y funciones faltantes, y el alcance listo para desplegarse a equipos no técnicos sigue limitado a consultas bastante simples
  • El enfoque de desarrollo está en un nuevo resolver, resolver bugs prioritarios, cerrar las brechas de funciones restantes para que pueda usarse en la mayoría de las consultas SQL estándar y añadir soporte experimental para módulos y proyectos de múltiples archivos
  • Como puntos de integración ofrece extensión de VS Code, integración con Jupyter, integración con QStudio, Jupyter magic, pyprql Docs y prqlc-js
  • El repositorio está compuesto por el compilador prqlc, escrito en Rust, y el área de contenido web web; prqlc compila PRQL a SQL e incluye CLI y bindings para varios lenguajes

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-27
Opiniones de Hacker News

  • Los ejemplos del sitio web https://prql-lang.org/ parecen ser la mayor ventaja de PRQL, sobre todo porque el SQL que genera es limpio e intuitivo, casi como algo que uno habría escrito a mano.
    Hace 10 o 15 años se creaban nuevas bases de datos como Mongo, Riak o Influx y se intentaba convencer a los desarrolladores de apps de usarlas en proyectos nuevos; hoy, en cambio, hay cada vez más opciones conservadoras como EdgeDB, TimescaleDB y PRQL, que ponen add-ons o preprocesadores de consultas sobre Postgres, por lo que son mucho más fáciles de adoptar.
    El esquema y las migraciones de Edge también son buenos, pero la sintaxis de PRQL es más intuitiva. Como en el código de aplicación ya existen muchas pipelines de transformación de datos, como las cadenas map/filter de TypeScript, los iteradores de Rust, los enumerable de Ruby, los streams de Java, .NET LINQ y Rx en varios lenguajes, el concepto resulta muy familiar. Es excelente poder obtener buen SQL desde PRQL, guardarlo, revisarlo después, ver el plan de ejecución y agregar índices donde haga falta.

    • Se ve bastante bien, pero parece diferir de SQL solo en detalles muy menores. Si Ruby fuera “una sintaxis más amigable que se transpila a Python”, siento que uno usaría solo lo que aprendió primero y no se molestaría en aprender lo otro.
      Los ejemplos hacen que SQL se vea arbitrariamente más verboso. from employees / select {id, first_name, age} / sort age / take 10 se ve mejor que un SELECT ... FROM ... ORDER BY ... LIMIT ... repartido en muchas líneas, pero el SQL real también puede escribirse como select id, first_name, age from employees order by age limit 10, y, salvo que no tiene llaves, la diferencia entre order by y sort es prácticamente una o dos letras.
    • No lo entiendo bien. Los ejemplos me parecen mucho menos legibles que SQL y no sé por qué debería usar esto.
      Poder cambiar el orden de las secciones de la consulta es algo de lo que todos se quejan en SQL, pero a cambio aparecen varios tipos de paréntesis, dos puntos y otra sintaxis sin motivo aparente, y tampoco parece hacer nada que SQL no pueda hacer ya. Me pregunto cuál es el atractivo.

  • Recientemente se fusionó el soporte para PRQL en ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686
    Por ahora es más bien experimental, y no está claro si realmente será utilizable o útil. También hay algunas preocupaciones relacionadas con Rust: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • Genial. Entonces me pregunto si eso significa que también se podrá usar en clickhouse-local.

  • Ojalá PRQL crezca mucho y se convierta en un lenguaje con soporte de primera clase en Postgres. El álgebra relacional es hermosa, pero SQL es un diseño inicial torpe que debió haber sido reemplazado hace décadas.
    Incluso Codd tenía quejas sobre SQL. Lo que inventó fue increíble, pero desde entonces hemos aprendido mucho sobre diseño de lenguajes de programación.

    • Es probable que la gente asocie tanto el álgebra relacional con SQL porque aprendió ambas juntas. Pero SQL es un lenguaje relacional muy malo y se desvía en muchos puntos, por ejemplo al romper con ORDER BY la idea central de que una relación es un conjunto sin orden.
      Este problema se manifiesta cuando envolverlo en una subconsulta hace que desaparezca el ordenamiento de la relación, lo cual es bastante inesperado. El modelo de datos de PRQL es muy parecido al modelo relacional, y la gran diferencia es que una relación se define como un arreglo de tuplas, por lo que tiene orden. Espero que PRQL llegue a conocerse como “lenguaje relacional Mk II”.
    • No es exactamente lo que querías, pero DuckDB tiene tanto una extensión PRQL [1] como una extensión Postgres [2], así que parece posible consultar una base de datos Postgres con PRQL desde ahí.
      También hay un plugin para DBeaver [3], aunque necesita más documentación y simplificar su uso, pero con eso también podría ser posible consultar Postgres con PRQL. Por último, con pyprql [4] se puede consultar Postgres desde un Jupyter notebook.
      [1]: https://github.com/ywelsch/duckdb-prql
      [2]: https://duckdb.org/docs/extensions/postgres_scanner.html
      [3]: https://github.com/PRQL/prql/issues/1643
      [4]: https://github.com/PRQL/pyprql
      Para referencia, soy colaborador de PRQL.
    • El álgebra relacional sigue siendo excelente. Lo que convirtió esa idea hermosa en un desastre difícil de creer fue SQL.
    • Aprendí SQL por primera vez cuando era adolescente, hace 20 años, y todavía recuerdo que entonces pensé que el lenguaje era raro y que literalmente se sentía al revés.
      En ese momento pensé que era porque no sabía lo suficiente como para entender por qué tenía que ser así, pero ahora sé que no hay motivo. SQL terminó siendo como un lenguaje natural: aunque no tenga sentido, no se puede refutar, simplemente hay que hablarlo. Pero SQL no es un lenguaje natural y podemos hacerlo mejor.
    • Siempre me desagradó tener que elegir qué consultar antes de elegir la fuente. La forma de esta sintaxis es mucho más intuitiva.

  • Si la principal queja sobre SQL es que no se puede cambiar el orden de SELECT, FROM, WHERE, entonces está bastante bien para ser un lenguaje diseñado en los años 70.
    En cambio, PRQL parece tener mucho ruido arbitrario en la sintaxis. No entiendo por qué debería preferir join side:left p=positions (p.id==employees.employee_id) en vez de LEFT JOIN positions AS p ON p.id = employees.employee_id.

    • El problema central de SQL es que está atrapado en una forma de escritura muy estricta, y eso no encaja bien con el flujo en el que pienso.
      Tiene mucho más sentido que, como en PRQL, cada paso de arriba hacia abajo sea una transformación del paso anterior. SQL requiere un manual de referencia, mientras que PRQL se siente como escribir directamente lo que quieres que haga la consulta. Dicho eso, la sintaxis de join de PRQL es muy mala; deberían haber mantenido palabras clave explícitas tipo left join, y podrían haber diseñado mejor los alias y la abreviación de columnas de join.
    • Mis quejas reales sobre SQL eran dos, y lo demás estaba bastante bien.
      Primero, no se puede usar más adelante una columna seleccionada previamente dentro del mismo select. No puedes escribir algo como gnarly_calculation AS some_value seguido de some_value * 2 AS some_value_doubled; tienes que envolverlo en una subconsulta. Segundo, no se puede especificar todas las columnas excepto algunas concretas. Cuando necesitas subir cálculos intermedios desde una subconsulta pero no los quieres en la salida final, no puedes decir algo como * EXCEPT some_value; tienes que enumerar todas las columnas de salida que quieres.
    • Tal vez porque estoy acostumbrado a R y al paradigma tidyverse, en general este paradigma y esta sintaxis me parecen bastante legibles.
      El ejemplo elegido puede ser un caso en el que los paréntesis y las comas ayudan mucho, pero en el contexto del lenguaje completo no está tan mal. : se usa de forma consistente como argumento con nombre, y = parece usarse para alias.
    • Porque ahora el tipo de join se vuelve un argumento de la operación join, y como la primera palabra de la sentencia es join, queda más claro cuál es la operación real.
      Incluso como ejemplo general de llamada a función, foo(bar) es mejor que “bar to foo()”.
    • El problema de SQL es el mismo que el de las declaraciones de variables al estilo C. Si lees el código en voz alta, puede sonar un poco mejor que la alternativa, pero en la práctica causa problemas de legibilidad y parseo/procesamiento.

  • PRQL 0.9 acaba de lanzarse hace unas horas, así que el timing es bueno. Las notas de la versión se pueden ver aquí: https://github.com/PRQL/prql/releases/tag/0.9.0
    Hay un cambio incompatible bastante grande: la sintaxis de tuplas pasa de [] a {}. Al principio parecían listas, pero con el tiempo nos dimos cuenta de que en realidad eran tuplas. Como dicen las notas de la versión, dejar libres los [] permitirá empezar pronto a soportar arreglos. Para referencia, soy contribuidor de PRQL.

  • La limitación de PRQL es que, por diseño, solo soporta SELECT. Si quieres insertar/modificar/eliminar datos, tienes que volver a SQL.
    El científico de datos del equipo puede darte una consulta en PRQL, pero para ponerla en un pipeline de datos real hay que traducirla a SQL. Estaría bien que al menos soportara una funcionalidad limitada, como insertar en una nueva tabla temporal. Por ejemplo, algo como from tracks / filter artist == "Bob Marley" / save bob_marley_tmp.

    • No veo por qué PRQL no podría soportar cambios de datos. Bastaría con tener operadores insert/update/delete que deban ir al final del pipeline y que reciban el nombre de la tabla como argumento.
      Un SQL como UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' podría escribirse en PRQL como from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters.
    • Sí, ahí perdí el interés.

  • El artículo que no puede faltar aquí: “I don't want to learn your garbage query language” [1]
    [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-garbage-query-language.html

    • Me encanta ese artículo, y también lo enlazamos desde el sitio web de PRQL.
      El objetivo de PRQL es ser un gran lenguaje para integrar y construir encima. No queremos crear N lenguajes para N bases de datos. PRQL siempre será open source y no vamos a crear un producto comercial, así que lo vemos como algo mucho más viable que los lenguajes específicos por base de datos o por producto. Soy desarrollador de PRQL.
    • La mejor refutación: https://www.scattered-thoughts.net/writing/against-sql/

  • Show HN anterior: https://news.ycombinator.com/item?id=31897430
    “Show HN: PRQL 0.2 – a better SQL” fue publicado por maximilianroos el 27 de junio de 2022 y tuvo 378 puntos y 161 comentarios.
    Post original donde se propuso por primera vez: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL” fue publicado por maximilianroos el 24 de enero de 2022 y tuvo 650 puntos y 295 comentarios.

  • Me recuerda a KQL de Microsoft: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL es excelente; lo extraño cada vez que uso SQL.
    • Es la única alegría que siento al usar Azure.

  • La sintaxis no es tan importante; lo importante es qué hace el optimizador.
    Muchos problemas de SQL hoy parecen una carga heredada. Como los motores antiguos no manejaban bien la sintaxis moderna, mucha gente se acostumbró a escribir consultas difíciles de leer, complejas y profundamente anidadas. Por ejemplo, con las expresiones de tabla comunes (CTE), se materializaban de inmediato, así que abundaba el estilo viejo como SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x))).
    Gracias a las mejoras en el manejo de CTE por parte de los motores, cada vez es más fácil escribir consultas comprensibles y componibles como WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE .... Si se suman funciones como las funciones de ventana modernas, SELECT * EXCEPT y otras más complejas como TOP X FOLLOWING, SQL puede volverse más simple.
    En este contexto, no creo que pequeñas mejoras en otras formas sintácticas como PRQL aporten grandes beneficios. Se puede reescribir como un pipeline que parece imperativo, pero el optimizador podría descartar parte de eso. Es cierto que hay cosas que SQL debería hacer mejor, pero todavía no he visto argumentos convincentes sobre diferencias externas o sintácticas.