TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Pql, a pipelined query language that compiles to SQL

262 点作者 ejcx大约 1 年前

36 条评论

memset大约 1 年前
This is really great! Maybe I&#x27;ll incorporate this into my own software (scratchdata&#x2F;scratchdb)<p>Question: it looks like you wrote the parser by hand. How did you decide that that was the right approach? I myself am new to parsers and am working on implementing the PostgREST syntax in go using PEG to translate to Clickhouse, which is to say, a similar mission as this project. Would love to learn how you approached this problem!
评论 #39546064 未加载
brikym大约 1 年前
It looks a lot like Kusto query language. Here is a kusto query:<p><pre><code> StormEvents | where StartTime between (datetime(2007-01-01) .. datetime(2007-12-31)) and DamageCrops &gt; 0 | summarize EventCount = count() by bin(StartTime, 7d) </code></pre> edit... yes it indeed was inspired by Kusto as they mention on the github Readme <a href="https:&#x2F;&#x2F;github.com&#x2F;runreveal&#x2F;pql">https:&#x2F;&#x2F;github.com&#x2F;runreveal&#x2F;pql</a>
评论 #39543615 未加载
darcien大约 1 年前
This is actually pretty awesome! I use KQL every few days for reading some logs from Azure App Insight. The syntax is pretty nice and you can make pretty complex stuff out of it. But that&#x27;s it, I can&#x27;t use KQL anywhere else outside Azure. With this, I can show off my KQL-fu to my teammates and surprise them with how fast you can write KQL-like syntax compared to SQL.
crooked-v大约 1 年前
What&#x27;s the reason to go for this over PRQL?
评论 #39543269 未加载
评论 #39543270 未加载
评论 #39542618 未加载
评论 #39541608 未加载
SuaveSteve大约 1 年前
Looks similar to PRQL[0].<p>Neither PRQL nor Pql seem to be able to do anything outside of SELECT like Preql[1] can.<p>I propose we call all attempts at transpiling to SQL &quot;quels&quot;.<p>[0] <a href="https:&#x2F;&#x2F;prql-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;prql-lang.org&#x2F;</a> [1] <a href="https:&#x2F;&#x2F;github.com&#x2F;erezsh&#x2F;Preql">https:&#x2F;&#x2F;github.com&#x2F;erezsh&#x2F;Preql</a>
mavam大约 1 年前
We&#x27;re developing TQL (Tenzir Query Language, &quot;tea-quel&quot;) that is very similar to PQL: <a href="https:&#x2F;&#x2F;docs.tenzir.com&#x2F;pipelines" rel="nofollow">https:&#x2F;&#x2F;docs.tenzir.com&#x2F;pipelines</a><p>Also a pipeline language, PRQL-inspired, but differing in that (i) TQL supports multiple data types between operators, both unstructured blocks of bytes and structured data frames as Arrow record batches, (ii) TQL is multi-schema, i.e., a single pipeline can have different &quot;tables&quot;, as if you&#x27;re processing semi-structured JSON, and (iii) TQL has support for batch and stream processing, with a light-weight indexed storage layer on top of Parquet&#x2F;Feather files for historical workloads and a streaming executor. We&#x27;re in the middle of getting TQL v2 [@] out of the door with support for expressions and more advanced control flow, e.g., match-case statements. There&#x27;s a blog post [#] about the core design of the engine as well.<p>While it&#x27;s a general-purpose ETL tool, we&#x27;re targeting primary operational security use case where people today use Splunk, Sentinel&#x2F;ADX, Elastic, etc. So some operators are very security&#x27;ish, like Sigma, YARA, or Velociraptor.<p>Comparison:<p><pre><code> users | where eventTime &gt; minus(now(), toIntervalDay(1)) | project user_id, user_email </code></pre> vs TQL:<p><pre><code> export where eventTime &gt; now() - 1d select user_id, user_email </code></pre> [@] <a href="https:&#x2F;&#x2F;github.com&#x2F;tenzir&#x2F;tenzir&#x2F;blob&#x2F;64ef997d736e9416e859bfcd5f6fa74970565204&#x2F;rfc&#x2F;004-query-language&#x2F;README.md">https:&#x2F;&#x2F;github.com&#x2F;tenzir&#x2F;tenzir&#x2F;blob&#x2F;64ef997d736e9416e859bf...</a><p>[#] <a href="https:&#x2F;&#x2F;docs.tenzir.com&#x2F;blog&#x2F;five-design-principles-for-building-a-data-pipeline-engine" rel="nofollow">https:&#x2F;&#x2F;docs.tenzir.com&#x2F;blog&#x2F;five-design-principles-for-buil...</a>
RedShift1大约 1 年前
InfluxDB tried to do this with InfluxQL but abandoned it, and are now back to SQL. The biggest problem I had with it when I tried it, was that is was simply too slow, queries were on average 6x slower than their SQL equivalents. I think a language like this is just too hard to optimize well.
评论 #39544545 未加载
评论 #39555198 未加载
helloericsf大约 1 年前
Wow, so many query languages, right? Do we really need another one? What&#x27;s the story behind that decision? Cheers.
评论 #39543190 未加载
评论 #39559795 未加载
smurda大约 1 年前
This is cool. Splunk Search Processing Language (SPL) is a real vendor lock-in feature. Once the team has invested time to get ramped up on SPL, and it gets integrated in your workflows, ripping out Splunk has an even higher switching cost.
anotherhue大约 1 年前
Similarities to PRQL: <a href="https:&#x2F;&#x2F;prql-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;prql-lang.org&#x2F;</a>
评论 #39544657 未加载
sinuhe69大约 1 年前
Their first example doesn&#x27;t look idiomatic at all:<p>SELECT * FROM &quot;users&quot; WHERE like (&quot;email&quot;, &#x27;gmail&#x27;)<p>Should “like” here be a user-defined function? Because that’s not the syntax for SQL-like. To which SQL version will Pql translate its queries?
评论 #39547755 未加载
vincnetas大约 1 年前
for anyone using anything more than basic SQL functionality so far this looks very limiting. No window functions, no agregate filtering, no data type specific functions (ranges).
shp0ngle大约 1 年前
How do I get parametered queries into this? can I? should I?<p>edit: guess I can&#x27;t<p><a href="https:&#x2F;&#x2F;pkg.go.dev&#x2F;github.com&#x2F;runreveal&#x2F;pql" rel="nofollow">https:&#x2F;&#x2F;pkg.go.dev&#x2F;github.com&#x2F;runreveal&#x2F;pql</a>
_v7gu大约 1 年前
Is the &quot;piping&quot; associative? As in, does it allow me to put `where eventTime &gt; minus(now(), toIntervalMinute(15)) | count` into a variable so I can use it later on multiple different tables&#x2F;queries? I remember failing to do the same thing with ggplot2 when I wanted to share styling between components. If the operator is not associative, then the reading order will have to be mixed since composing will require functions (and Go doesn&#x27;t have pipes&#x2F;UFCS)
prasoonds大约 1 年前
One potential advantage of these compile-to-SQL languages seems to be - they might be easier to tune a codegen LLM on. SQL is very verbose and IME, english -&gt; SQL doesn&#x27;t really work too well, even in high end products (i.e. pricy SaaS offerings using presumably GPT-4)<p>My hunch is tuning english prompts on less verbose, more &quot;left to right&quot; flowing languages might yield better results.
alfalfasprout大约 1 年前
At this stage I feel that the natural evolution for SQL is instead to use english to describe what you want and have an LLM generate SQL. Often with comments.<p>For some reason, a lot of these SQL alternatives seem to be syntactic preference and not much simpler or clearer than the original.
评论 #39542406 未加载
评论 #39543228 未加载
评论 #39542264 未加载
评论 #39542998 未加载
评论 #39542289 未加载
评论 #39543273 未加载
评论 #39542391 未加载
mcphage大约 1 年前
Their very first example has issues:<p>&gt; users &gt; | where like(email, &#x27;gmail&#x27;) &gt; | count<p>becomes<p>&gt; WITH &gt; &quot;__subquery0&quot; AS ( &gt; SELECT &gt; * &gt; FROM &gt; &quot;users&quot; &gt; WHERE &gt; like (&quot;email&quot;, &#x27;gmail&#x27;) &gt; ) &gt; SELECT &gt; COUNT(*) AS &quot;count()&quot; &gt; FROM &gt; &quot;__subquery0&quot;;<p>Fetching everything from the users table can be a ton slower than just running a count on that table, if the table is indexed on email. I had to deal with that very problem this week.
评论 #39544259 未加载
评论 #39544628 未加载
评论 #39544224 未加载
pknerd大约 1 年前
Sorry I might be dumb but why do we need this?
评论 #39543711 未加载
评论 #39543741 未加载
wingi大约 1 年前
The first example is worse. Why learning a piping syntax instead learning SQL?
dkga大约 1 年前
The R {dbplyr} package is also a very good way in practice to pipe SQL.
评论 #39544573 未加载
hans_castorp大约 1 年前
What target database is that in the examples?<p><pre><code> like (&quot;email&quot;, &#x27;gmail&#x27;) minus (now (), toIntervalDay (1)) </code></pre> are non-standard functions&#x2F;conditions
swman大约 1 年前
Maybe I’m totally missing it but why would I use it over sql? All those companies have their own flavor DSL so are you saying this is to standardize using it? Thanks
评论 #39547265 未加载
nitrix大约 1 年前
Pipelining is cool, though this could&#x27;ve easily just been a library with nice chaining and combinators in your language of choice (seems to be Go here).
评论 #39544682 未加载
jkn23jn23jn大约 1 年前
So basically the same as C# LINQ feature that allows you to automatically generate SQL and perform database operations without using SQL language.
Cloudef大约 1 年前
I never liked the original SQL syntax, it&#x27;s weird. It&#x27;s one of the few places where I think using s-exprs would&#x27;ve made more sense.
ben_jones大约 1 年前
I’m glad this exists but would caution extensibility as the most important thing for devs to consider when picking there “ORM” stack especially in terse Golang.<p>For that I use squirrel which uses the builder pattern to compose sql strings. Keeping it as strings and interfaces allow it to be very easily extended, for example I was able to customize it to speak SOQL (salesforce). plenty of downide though.
outside1234大约 1 年前
Serious question - in this day and age why not just as GPT4 in English to write the SQL you need?
评论 #39550530 未加载
Alifatisk大约 1 年前
Reminds me of how ActiveRecord works in Rails
krick大约 1 年前
I don&#x27;t get it. These examples are kinda uninspiring, generated SQL output being unnecessarily complicated doesn&#x27;t help. I haven&#x27;t used PRQL, but at least it&#x27;s pretty obvious from examples, how it&#x27;s nicer to use than SQL. But this one — yeah, examples on the left are &quot;nicer&quot; than convoluted output on the right, but if you write SQL <i>normally</i>, it&#x27;s basically just a lot of &quot;|&quot; and table name in the beginning, instead of in the middle. So what&#x27;s the point?
neonsunset大约 1 年前
Another day, another framework that tries to reinvent a limited subset of C#&#x27;s LINQ query syntax :)
SomeoneFromCA大约 1 年前
SQL in the examples is deliberately convoluted, to make pql look more elegant.
otabdeveloper4大约 1 年前
Not to be confused with Prql.
gtroja大约 1 年前
The only thing I like in SQL is that is almost the same language in decades. Learn it once and you&#x27;re done. If you really need, you could write macros yourself. I don&#x27;t see the value of learning a new language to do the same thing
评论 #39543219 未加载
评论 #39544936 未加载
评论 #39542761 未加载
评论 #39543350 未加载
danpalmer大约 1 年前
The &quot;Why?&quot; questions are getting downvoted, but to dissect the why section from the page a little...<p>&quot;designed to be small and efficient&quot; – adding a layer on top of SQL is necessarily less efficient, adding a layer of indirection on underlying optimisations means it is likely (but not guaranteed) to also generate less efficient queries.<p>&quot;make developing queries simple&quot; – this seems to be just syntactic preference. The examples are certainly shorter, but in part that&#x27;s the SQL style used.<p>I think it either needs more evidence that the syntax is actually better or cases it simplifies, the ways in which it can optimise that are hard in SQL, or it perhaps needs to be more honest about the intent of the project being to just be a different interface for those who prefer it that way.<p>It&#x27;s an interesting exercise, and I&#x27;m glad it exists in that respect, and hope the author enjoyed making it and learnt something from it. That can be enough of a why!
评论 #39541802 未加载
评论 #39544020 未加载
评论 #39542330 未加载
评论 #39546028 未加载
评论 #39545110 未加载
jerrygenser大约 1 年前
This seems really cool. This is not meant to be a negative comment - why does it matter that it&#x27;s written in Go? It&#x27;s stated multiple times but could this be written in multiple other languages and still be functionally the same?
评论 #39545567 未加载
xiaodai大约 1 年前
Piping the results of each query into text is definitely NOT efficient