Pql, uma linguagem de consulta em pipeline que compila para SQL

Artigo original ↗ Discussão no Hacker News ↗

Uma nova linguagem de consulta em pipeline chamada Pql, inspirada em ferramentas como Kusto e o SPL do Splunk, busca oferecer uma alternativa mais legível e focada em segurança ao SQL, ao mesmo tempo em que compila para SQL padrão para execução. Os comentaristas debatem se essa abstração extra traz benefícios reais em comparação com opções maduras como PRQL, bibliotecas no estilo LINQ ou simplesmente escrever SQL diretamente, levantando preocupações sobre desempenho, recursos ausentes (por exemplo, funções de janela) e o custo de longo prazo de manter mais uma DSL. Outros argumentam que a complexidade do SQL, seus dialetos inconsistentes e o tratamento inadequado de conceitos como null justificam experimentos como o Pql, especialmente se eles se integrarem de forma limpa com bancos de dados e ferramentas existentes.

Motivação e Público-Alvo

  • Projetada como uma linguagem pequena, em pipeline, que compila para SQL, fortemente inspirada em linguagens de consulta no estilo Kusto / SPL.
  • Voltada especialmente para engenheiros e analistas de segurança que não gostam de SQL e já estão acostumados com KQL, Splunk SPL, Sumo, etc.
  • Visto como uma forma de obter ergonomia semelhante à do KQL por cima de mecanismos SQL gerais e reduzir o aprisionamento a fornecedor causado por DSLs proprietárias de consulta a logs.

Comparação com SQL

  • Defensores gostam do estilo de pipeline linear, da esquerda para a direita, e da sintaxe mais curta, semelhante à do KQL.
  • Críticos argumentam que os exemplos comparam um Pql “bonito” com SQL deliberadamente convoluto; SQL idiomático poderia ser quase tão simples.
  • Alguns dizem que a estabilidade e ubiquidade do SQL superam os benefícios de aprender mais uma DSL; outros veem o SQL como fundamentalmente estranho ou “terrível”.

Relação com Outras Linguagens de Consulta (PRQL, LINQ, etc.)

  • Comparações fortes com PRQL: ambas compilam para SQL com sintaxe em pipeline.
  • Questiona-se por que não reutilizar PRQL; as respostas citam público diferente, preferências de sintaxe e o desejo de uma implementação pura em Go.
  • Também comparado a LINQ, dbplyr, CoffeeScript/TypeScript sobre JS e vários projetos semelhantes “pós-SQL” (TQL, XTQL, Preql).

Desempenho e Planejamento de Consultas

  • Preocupação de que a saída pesada em CTE do Pql (subconsultas WITH) possa ser lenta ou forçar ordens ruins de junção.
  • Outros observam que mecanismos modernos frequentemente inlinam CTEs, então casos simples não deveriam ser um problema; mas o impacto em consultas complexas não está claro.
  • Ceticismo geral de que outra camada de abstração possa ser “mais eficiente” do que escrever SQL diretamente, além da produtividade do desenvolvedor.

Escolhas de Implementação (Go, Bindings, Parsing)

  • Debate sobre usar Go versus encapsular o PRQL baseado em Rust: Go + bindings C funcionam, mas alguns veem o FFI em Go como desajeitado; outros dizem que o overhead hoje é pequeno.
  • O autor escreveu o parser manualmente; outros comentaristas compartilham experiências de construir parsers de descida recursiva como algo educativo e flexível.

Tratamento de Null e Semântica

  • O Pql herda o comportamento de NULL do SQL, já que apenas transpila; ele não corrige os problemas da lógica de três valores.
  • Alguns argumentam que um design melhor usaria tipos Option/Maybe, mas isso exigiria uma linguagem fundamentalmente diferente, não apenas uma interface SQL.

LLMs vs DSLs

  • Vários observam que ferramentas de LLM para SQL são promissoras, mas pouco confiáveis: boas para rascunhos iniciais, não para consultas críticas em termos de correção.
  • O Pql é apresentado por alguns como uma ponte mais determinística: mais fácil que SQL para certos usuários, mas ainda explícito e verificável.

Limitações e Ceticismo

  • Comentadores observam a ausência de recursos avançados de SQL (funções de janela, filtragem de agregados, funções específicas por tipo de dado, parâmetros).
  • Alguns temem a complexidade adicionada, uma segunda “camada” sobre o planejador de consultas e mais uma linguagem de consulta de vida curta.
  • Outros estão entusiasmados com a ergonomia semelhante à do KQL sobre backends SQL padrão e acolhem mais experimentação nesse espaço.