FRESH

Hacker News

Pipelined Relational Query Language, Pronounced "Prequel"

65 points by dmit

by jelder

1 subcomments

DuckDB had the right idea: just allow some flexibility in the relative order of the `select` and `from` clauses, and make a few other concessions for ergonomics. This then becomes valid:

    from events      -- table is first, which enables autocomplete
    select
        count(),     -- * is implied, easier to type
        customer_id, -- trailing commas allowed everywhere
    group by all     -- automatically groups by all non-aggregate columns
    order by all     -- orders rows by all columns in selected order

https://duckdb.org/docs/stable/sql/dialect/friendly_sql

by thesz

4 subcomments

SQL is not a pipeline, it is a graph.
Imagine three joins of three queries A,B and C, where first join J1 joins A and B, second join J2 joins A and C and third join J3 joins J1 and J2. Note that I said "queries," not "tables" - these A, B and C can be complex things one would not want or be able to compute more than once. Forget about compute, A, B and C can be quite complex to even write down and the user may really do not want to repeat itself. Look at TPC-DS, there are subqueries in the "with" sections that are quite complex.
This is why pipeline replacements for SQL are more or less futile efforts. They simplify simple part and avoid touching complex one.
I think that something like Verse [1] is more or less way to go. Not the Verse itself, but functional logic programming as an idea, where you can have first class data producers and effect system to specify transactions.
[1] https://en.wikipedia.org/wiki/Unreal_Engine#Verse

by dewey

3 subcomments

Every time I see these layers on top of SQL I think: Just use regular, boring SQL
It will be around for a long time, there's an infinite number of resources and examples for it and if you ever have to onboard someone into your code they don't need to learn something new. You can get pretty far by just using CTEs to "pipeline".

by Taikonerd

0 subcomment

Google's "pipe syntax" is a similar idea: [0]
It's not as elegant as PRQL, because of course it's bolted onto the existing SQL syntax, rather than a redesign from scratch. But it has a big name behind it, and it's actually running in prod in Google Cloud... so it might have more momentum.
[0]: https://cloud.google.com/blog/products/data-analytics/simpli...

by hardwaregeek

0 subcomment

There’s probably a good reason why not, but I’d love a query language with sum types. They just feel like a natural way to model a lot of data

by Taikonerd

2 subcomments

Is this project stalling out? The last post on the "posts" page is from March 2023. But the last commit to the git repo was last week...

by zerkten

0 subcomment

Kusto is similar: https://learn.microsoft.com/en-us/kusto/query/

by latexr

3 subcomments

The title of the submission is literally the first line on the website.
I always find that funny. If you have to provide a pronunciation guide for your product, perhaps consider a different name. I guarantee you’ll still have people pronouncing each individual letter, either because they don’t know or because it’ll be less ambiguous.

0 subcomment

by infogulch

0 subcomment

This looks pretty nice to use!
How does it work if you want to join multiple complex subqueries?
How far can a new query language like this go? Could this be added as a native query language in e.g. postgresql?

by bob1029

1 subcomments

"Pipelined" SQL already exists in the form of common table expressions. I don't know of any providers where this is not available. SQLite has had support since 2014.

by jdkfjdo

2 subcomments

Sometimes I wonder if the only thing needed in SQL is to switch the order of FROM and SELECT. I think that would satisfy many people who are bothered by the syntax.

0 subcomment

by hbarka

2 subcomments

Procedural language fanatics have been trying for years to overturn the best declarative language for relational data.