PRQL: linguagem de consulta relacional em pipeline

 (github.com/PRQL)
4 pontos por GN⁺ 2023-07-27 | 1 comentários | Compartilhar no WhatsApp
  • PRQL é uma linguagem moderna para transformar dados, buscando ser uma alternativa ao SQL que, como SQL, seja legível, explícita e declarativa
  • As consultas são compostas como um pipeline lógico, em que cada etapa de transformação recebe o resultado anterior, e oferecem suporte a abstrações como variáveis e funções
  • O PRQL é compilado para SQL para que possa ser usado com qualquer banco de dados que use SQL
  • Os exemplos da linguagem usam transformações como from, filter, derive, group, aggregate, sort e take; filter substitui os papéis do WHERE e do HAVING do SQL
  • Entre os recursos de sintaxe estão notação clara de datas, coalesce, variáveis que referenciam outras variáveis, F-strings semelhantes às do Python, S-strings que usam SQL como escape hatch, notação de ordenação decrescente e expressões de intervalo
  • Oferece o PRQL Playground para experimentação no navegador, o PRQL Book como documentação da linguagem e o prql-lang.org com comparações e exemplos em SQL
  • Em junho de 2026, pode ser usado por meio de integrações ou bindings de linguagem compatíveis, mas ainda restam alguns bugs e funcionalidades ausentes, e o escopo pronto para implantação voltada a equipes não técnicas permanece limitado a consultas bastante simples
  • O foco de desenvolvimento é o trabalho em um novo resolver, a correção de bugs prioritários, o fechamento das lacunas de funcionalidades restantes para permitir uso na maior parte das consultas SQL padrão e a adição de suporte experimental a módulos e projetos com múltiplos arquivos
  • Como pontos de integração, oferece extensão para VS Code, integração com Jupyter, integração com QStudio, Jupyter magic, pyprql Docs e prqlc-js
  • O repositório é composto pelo compilador prqlc, escrito em Rust, e pela área de conteúdo web web; o prqlc compila PRQL para SQL e inclui uma CLI e bindings para várias linguagens

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-27
Opiniões do Hacker News

  • Os exemplos no site https://prql-lang.org/ parecem ser a maior vantagem do PRQL, especialmente porque o SQL gerado é limpo e intuitivo, com uma forma que alguém poderia ter escrito à mão
    Há 10~15 anos, criavam-se novos bancos de dados como Mongo, Riak e Influx e tentava-se convencer desenvolvedores de apps a usá-los em novos projetos; hoje, porém, há cada vez mais opções conservadoras, como EdgeDB, TimescaleDB e PRQL, que colocam addons ou pré-processadores de consulta sobre o Postgres, o que torna a adoção muito mais fácil
    O esquema e as migrações do Edge também são bons, mas a sintaxe do PRQL é mais intuitiva. Como já existem muitos pipelines de transformação de dados no código de aplicações — como cadeias de map/filter do TypeScript, iteradores do Rust, enumerables do Ruby, streams do Java, LINQ do .NET e Rx em várias linguagens — o conceito é muito familiar. É ótimo poder extrair bom SQL do PRQL, salvá-lo, verificá-lo depois, ver o plano de execução e adicionar índices onde for necessário

    • Parece bem interessante, mas parece diferir do SQL só em detalhes muito pequenos. Se Ruby fosse “uma sintaxe mais amigável transpilada para Python”, a sensação é que eu usaria apenas a que aprendi primeiro e nem me daria ao trabalho de aprender a outra
      Os exemplos fazem o SQL parecer arbitrariamente mais verboso. from employees / select {id, first_name, age} / sort age / take 10 parece melhor do que SELECT ... FROM ... ORDER BY ... LIMIT ... dividido em muitas linhas, mas o SQL real também pode ser escrito como select id, first_name, age from employees order by age limit 10; em vez de chaves, a diferença fica mais ou menos entre order by e sort, ou seja, algo próximo de uma ou duas letras de diferença
    • Não entendi muito bem. Os exemplos parecem muito menos legíveis do que SQL, e não sei por que eu deveria usar isso
      Poder mudar a ordem das seções da consulta é algo de que todo mundo reclama no SQL, mas em troca entram vários tipos de parênteses, dois-pontos e outras sintaxes sem motivo aparente, e também não parece realizar nada que o SQL já não faça. Fico curioso para saber qual é o ponto de atração

  • Recentemente foi mesclado suporte a PRQL no ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686
    Por enquanto ainda parece mais um experimento, e não está claro se será realmente utilizável ou útil. Também há algumas preocupações relacionadas a Rust: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • Legal. Então fico curioso se isso significa que também será possível usar no clickhouse-local

  • Seria bom se o PRQL crescesse bastante e se tornasse uma linguagem com suporte de primeira classe no Postgres. A álgebra relacional é linda, mas SQL é um projeto inicial desajeitado que deveria ter sido substituído décadas atrás
    Até Codd tinha insatisfações com SQL. O que ele inventou é impressionante, mas aprendemos muito sobre design de linguagens de programação desde então

    • As pessoas provavelmente associam álgebra relacional e SQL com frequência porque aprenderam as duas juntas. Mas SQL é muito ruim como linguagem relacional e se desvia em vários pontos, por exemplo quebrando com ORDER BY o conceito central de que relações são conjuntos sem ordem
      Esse problema aparece quando, ao envolver em uma subconsulta, a ordenação da relação desaparece, o que é bastante inesperado. O modelo de dados do PRQL é muito parecido com o modelo relacional; a grande diferença é que a relação é definida como um array de tuplas, portanto tem ordem. Espero que o PRQL fique conhecido como “linguagem relacional Mk II”
    • Não é exatamente o que você queria, mas o DuckDB tem tanto uma extensão PRQL [1] quanto uma extensão Postgres [2], então parece que ali seria possível consultar um banco de dados Postgres com PRQL
      Também existe um plugin para DBeaver [3], que ainda precisa de mais documentação e simplificação de usabilidade, mas com ele também pode ser possível consultar Postgres com PRQL. Por fim, usando o pyprql [4], dá para consultar Postgres em um 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 referência, sou contribuidor do PRQL
    • A álgebra relacional continua excelente. Quem transformou aquela bela ideia em uma bagunça inacreditável foi o SQL
    • Aprendi SQL pela primeira vez quando era adolescente, há 20 anos, e ainda me lembro de ter pensado na época que a linguagem era estranha e literalmente parecia de trás para frente
      Na época, achei que era porque eu não sabia o suficiente para entender por que precisava ser assim, mas agora sei que não há motivo para isso. SQL acabou ficando como linguagem natural: mesmo que não faça sentido, não dá para contestar, é só falar. Mas SQL não é linguagem natural, e dá para fazer melhor
    • Nunca gostei da forma de escolher o que consultar antes de escolher a fonte. O formato da sintaxe aqui é muito mais intuitivo

  • Se a principal reclamação sobre SQL é que não dá para mudar a ordem de SELECT, FROM, WHERE, então, para uma linguagem projetada nos anos 70, ela está até bem boa
    Por outro lado, o PRQL parece ter bastante ruído arbitrário na sintaxe. Não entendo por que eu deveria preferir join side:left p=positions (p.id==employees.employee_id) a LEFT JOIN positions AS p ON p.id = employees.employee_id

    • O problema central do SQL é que ele fica preso a uma forma de escrita muito rígida, e isso não combina bem com o fluxo em que eu penso
      Um modelo como o do PRQL, em que cada etapa de cima para baixo é uma transformação da etapa anterior, faz muito mais sentido. SQL exige um manual de referência, enquanto PRQL parece que você escreve diretamente o que quer que a consulta faça. Dito isso, a sintaxe de join do PRQL é muito ruim; eles deveriam ter mantido palavras-chave explícitas do tipo left join, e também poderiam ter feito melhor a abreviação de aliases e colunas de junção
    • As reclamações reais sobre SQL eram duas; o resto era bem aceitável
      Primeiro, dentro do mesmo select, não dá para usar depois uma coluna selecionada anteriormente. Não dá para escrever algo como some_value * 2 AS some_value_doubled depois de gnarly_calculation AS some_value; é preciso envolver em uma subconsulta. Segundo, não dá para especificar todas as colunas exceto algumas específicas. Quando você precisa trazer um cálculo intermediário de uma subconsulta, mas não o quer na saída final, não dá para dizer algo como * EXCEPT some_value; é preciso listar todas as colunas de saída desejadas
    • Talvez por eu estar acostumado com R e o paradigma do tidyverse, de modo geral esse paradigma e essa sintaxe parecem bastante legíveis
      Os exemplos escolhidos podem ser casos em que parênteses e vírgulas ajudariam bastante, mas, no contexto da linguagem como um todo, não é tão ruim. : é usado de forma consistente como argumento nomeado, e = parece ser usado para aliases
    • Porque agora o tipo de join vira um argumento da operação join, e a primeira palavra da instrução é join, deixando mais claro qual é a operação real
      Mesmo como exemplo de chamada de função comum, foo(bar) é melhor do que “bar to foo()”
    • O problema do SQL é o mesmo das declarações de variáveis no estilo C. Quando você lê o código em voz alta, ele parece um pouco melhor que as alternativas, mas na prática causa problemas de legibilidade e parsing/processamento

  • O PRQL 0.9 acabou de ser lançado há poucas horas, então o timing é bom. As notas de lançamento podem ser vistas aqui: https://github.com/PRQL/prql/releases/tag/0.9.0
    Há uma mudança incompatível considerável: a sintaxe de tuplas mudou de [] para {}. No começo, isso parecia listas, mas com o tempo percebemos que, na verdade, eram tuplas. Como dizem as notas de lançamento, deixar [] livre nos permitirá começar a oferecer suporte a arrays em breve. Para constar, sou contribuidor do PRQL

  • Uma limitação do PRQL é que, por design, ele só dá suporte a SELECT. Para inserir/alterar/excluir dados, é preciso voltar ao SQL
    O cientista de dados da equipe pode entregar consultas em PRQL, mas, para colocá-las em um pipeline de dados real, será preciso traduzir para SQL. Seria bom se ao menos houvesse suporte a uma funcionalidade limitada, como inserir em uma nova tabela temporária. Algo como from tracks / filter artist == "Bob Marley" / save bob_marley_tmp

    • Não vejo motivo para o PRQL não poder oferecer suporte a alterações de dados. Bastaria ter operadores insert/update/delete que venham no fim do pipeline e recebam o nome da tabela como argumento
      Um SQL como UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' poderia ser escrito em PRQL como from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters
    • Sim, foi aqui que perdi o interesse

  • Um texto que não pode ficar de fora aqui: “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

    • Gosto muito desse texto, e ele também está linkado no site do PRQL
      O objetivo do PRQL é ser uma ótima linguagem para integrar e construir em cima. Não queremos criar N linguagens para N bancos de dados. Como o PRQL sempre será open source e não vai criar um produto comercial, acho que ele é muito mais viável do que linguagens específicas por banco de dados ou por produto. Sou desenvolvedor do PRQL
    • A melhor refutação: 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” foi publicado por maximilianroos em 27 de junho de 2022, teve 378 pontos e 161 comentários
    Post original em que foi proposto pela primeira vez: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL” foi publicado por maximilianroos em 24 de janeiro de 2022, teve 650 pontos e 295 comentários

  • Lembra o KQL da Microsoft: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL é excelente; sinto falta dele toda vez que uso SQL
    • É a única alegria que tenho ao usar Azure

  • A sintaxe não é tão importante; o que importa é o que o otimizador faz
    Muitos problemas atuais de SQL parecem uma bagagem antiga. Como os motores antigos não lidavam bem com sintaxes modernas, muita gente foi treinada a escrever consultas difíceis de ler, complexas e profundamente aninhadas. Por exemplo, expressões de tabela comuns (CTEs) eram imediatamente materializadas, e por isso proliferava aquele estilo antigo como SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x)))
    Graças a melhorias no tratamento de CTEs pelos motores, está ficando cada vez mais fácil escrever consultas compreensíveis e composicionais como WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE .... Com recursos como funções de janela modernas, SELECT * EXCEPT e funcionalidades mais complexas como TOP X FOLLOWING, o SQL pode ficar mais simples
    Nesse cenário, não vejo pequenos aprimoramentos em outra forma sintática, como PRQL, trazendo grandes benefícios. Dá para reescrever como um pipeline que parece imperativo, mas o otimizador pode descartar parte disso. É verdade que há coisas em que o SQL precisa melhorar, mas ainda não vi um argumento convincente para diferenças superficiais ou sintáticas