Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PRQL: Pipelined Relational Query Language

github.com

Post reply on HN
Print view View original

121–130 of 214 posts

Re: PRQL: Pipelined Relational Query Language

#121

Post by pragmatic »

Pxtl wrote: post #102
andrewl-hn wrote: post #86

Earlier quoted context omitted.

I use CTEs, window functions, and groupings all the time when I write reporting queries. These things tend to be much more verbose in raw SQL, and ORMs / Query Builders either do not support some of these features at all or do very poor job (like, force me to put raw SQL substrings in my code), or force to write DSLs that are even more verbose than raw SQL. Look at corresponding PRQL samples, and you may see an appea…

While there's some stuff in C#/LINQ/EF that's more verbose (left joins are often a nightmare) or not-supported, I'll always say that I prefer writing queries in EF than in SQL, at least when dealing with SQL features that are supported by EF (which is a lot of them, it's a very expressive dialect). But EF lets you start with FROM, lets you do whichever keywords you need in whichever order (instead of WHERE -> GROUP B…

The downside though is you have to grab the sql it’s generating somehow to try to optimize it, figure out what crazy cross apply madness it’s going or to figure out why it’s blowing sql servers recursion limit.

I prefer to avoid linq syntax now. It’s a false economy.

Re: PRQL: Pipelined Relational Query Language

#122

Post by pragmatic »

hn_throwaway_99 wrote: post #120
t8sr wrote: post #16

Earlier quoted context omitted.

I don't get that - to me the examples are much less readable than SQL and I don't understand why I should want to use this. Like, yes, you can reorder the query sections, which seems to be everyone's complaint about SQL, but then you also have multiple types of brackets, colons and other syntax for no reason, all while not really accomplishing anything SQL doesn't already do. What's the attraction?

The attraction is that, especially for more complicated queries with complex joins, subqueries, aggregates, etc., that the structure of PRQL much more closely matches the "English", mental-model of the query. I can just read PRQL linearly, from top to bottom, and at each point I know what is being "pipelined" into the next phase of the query. With SQL I have to look all over the place. And it's not just that FROM sho…

The downside is, debugging what actual sql this monstrosity spits out.

Re: PRQL: Pipelined Relational Query Language

#125

Post by snthpy »

zX41ZdbW wrote: post #116
snthpy wrote: post #106

Earlier quoted context omitted.

That's awesome! ClickHouse is a great system by all accounts and I've been meaning to try out ClickHouse Local. I'm more familiar with DuckDB and they've also been doing some great innovation on the SQL front. I don't know offhand if they can also do the forward referencing thing but they allow putting the FROM first and having GROUP BY ALL etc.. It's great to see all this innovation happening in the SQL and Query La…

It is strange to hear about innovation in DuckDB - I see that they are gradually re-implementing the stuff already existing in ClickHouse. Sometimes they do a better job at promoting it.

That's probably true but the big differentiator was that DuckDB can run in your python process so there's very low fiction to adopt it.

My impression of ClickHouse was that it was more like postgresql in that regard, i.e. OLAP : OLTP as ClickHouse : Postgres as DuckDB : SQLite.

clickhouse-local may have closed the gap on that though. Can you embed it in Python as a library?

Re: PRQL: Pipelined Relational Query Language

#126

Post by sdesol »

snthpy wrote: post #85
sdesol wrote: post #66

This is from the GitHub page > PRQL is being actively developed by a growing community You can see this at https://devboard.gitsense.com/PRQL which shows a good mix of new and not new contributors. Not sure why there was a spike in the last couple of days though. Maybe the maintainers that in this thread can comment on this. Full Disclosure: This is my tool

Great tool! Thanks for sharing that. Regarding the activity, there's been a lot of preparation for the 0.9 release. As to the new contributors, I don't know the reasons for that but all contributions are very welcome. It's a very welcoming community and a great way to make an impact! Full Disclosure: PRQL contributor

Thanks for the insights. You might also want to add a "good-first-issue" topic an/or labels to your project to signal how open you guys are to new contributors. In the near future, I'm going to start surfacing projects with these labels/topics.

Re: PRQL: Pipelined Relational Query Language

#127

Post by hn_throwaway_99 »

pragmatic wrote: post #122
hn_throwaway_99 wrote: post #120

Earlier quoted context omitted.

The attraction is that, especially for more complicated queries with complex joins, subqueries, aggregates, etc., that the structure of PRQL much more closely matches the "English", mental-model of the query. I can just read PRQL linearly, from top to bottom, and at each point I know what is being "pipelined" into the next phase of the query. With SQL I have to look all over the place. And it's not just that FROM sho…

The downside is, debugging what actual sql this monstrosity spits out.

Two points:

1. The SQL that I've seen output by PRQL isn't monstrous, at least no more than it would be coding by hand.

2. I do agree that I don't think PRQL will have much uptake until it is baked in to DB systems, at least as a plugin. One reason (among many) that I hate ORM systems is that with native SQL it's very easy for me to just capture a SQL statement from my DB logs and then search my code for an offending statement. But given how PRQL is transpiled, I don't see any reason it couldn't be essentially part of the query planner, so that query logs etc. are reported in PRQL and not SQL. E.g. the query planner already takes text (SQL) -> Query Plan, it seems rather straightforward to go text (PRQL) -> text (SQL) -> Query Plan, with the SQL intermediate just being an implementation detail I don't have to care about as a DB user.

Re: PRQL: Pipelined Relational Query Language

#128

Post by slotrans »

pjot wrote: post #90
andrewl-hn wrote: post #86

Earlier quoted context omitted.

I use CTEs, window functions, and groupings all the time when I write reporting queries. These things tend to be much more verbose in raw SQL, and ORMs / Query Builders either do not support some of these features at all or do very poor job (like, force me to put raw SQL substrings in my code), or force to write DSLs that are even more verbose than raw SQL. Look at corresponding PRQL samples, and you may see an appea…

At least we can all agree on leading commas though!

death before trailing commas

Re: PRQL: Pipelined Relational Query Language

#129

Post by slotrans »

Hot takes: SQL is good. Great, in fact.

Not just in what it's capable of doing, but in form. It has warts, yeah, but over the years I've been writing it I've realized most of them are there for a reason. To me it's more than useful, it's beautiful. It's the absolute last thing I want a replacement for.

Re: PRQL: Pipelined Relational Query Language

#130

Post by strokirk »

mulmen wrote: post #34
spullara wrote: post #19

Earlier quoted context omitted.

it seems like any SQL parser could let you put FROM first and solve a lot of the annoyances of SQL

The stiff syntax is a feature . The infamous 1000 line sales report query is already a bear to maintain. If you get a clever developer reordering syntax it will only be worse.

It’s certainly not a feature. A lot of important SQL usage is ad-hoc queries, and they are more annoying to type than they should be.
Post reply on HN