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

Show HN: PRQL in PostgreSQL

github.com

Post reply on HN
Print view View original

31–40 of 142 posts

Re: Show HN: PRQL in PostgreSQL

#31

Post by CuriouslyC »

sph wrote: post #19
CuriouslyC wrote: post #17

Earlier quoted context omitted.

This seems like a micro-optimization to me. That's faster to write, but you pay for that with extra tooling and an abstraction layer that you now have to train or hire for, and I'm not sure that's a good payoff. This idea seems like it'd be better as an editor plugin that lets you write shorthand and have it automatically expanded into correct SQL rather than as a build time thing.

You can apply this logic to choosing a high level language vs writing assembly code. Yes the pipeline is more complex, there are more tools and more syntax to track, but the benefits are pretty clear (or we'd all be writing UI code in hand written asm) While leaky abstractions are a huge problem, the thing about abstractions is that, if they are any good, the benefits and improvements to productivity outweigh the neg…

I don't think the analogy of with js/etc and assembly is quite fair, the difference in readability between this and sql isn't on that order, and if it were I'd be a lot more bullish on this project :)

Re: Show HN: PRQL in PostgreSQL

#32

Post by haspok »

CuriouslyC wrote: post #23
haspok wrote: post #18

Earlier quoted context omitted.

One notable reason is being database-agnostic. Like ORM's, if you can generate SQL you can generate database-specific SQL as well. SQL is also quite verbose in places (JOINs are the most trivial example), and lack a decent amount of abstraction (CTEs are relatively low level). Updating a large set of FK'd tables can be a nightmare (this is what ORMs shine at). Finally, some modern additions are quite unreadable, Post…

Database agnosticism is so 2010. There's very little reason to choose a DB other than postgres, and if you have a reason to choose a specific niche db you're not probably not going to be migrating away from it any time soon. CTEs are a first step in structuring queries to make them decomposable. You can extract CTEs to functions and mark them stable and it's logically equivalent to the original query.

> There's very little reason to choose a DB other than postgres

Sure, if you are a startup, or write your own code. But for most people the choice of database(s) is a given, and they are not in a position to challenge that. At the end of the day, Oracle has to make a living, too...

Re: Show HN: PRQL in PostgreSQL

#33

Post by philipodonnell »

I often wonder if NL-SQL tasks would benefit from an intermediate query language that is more compatible with the next-logical token approach that is used to generate the code. Obviously there is less of this in the training set, but if it transpires in a testable way, you could generate training data yourself from known good sql queries? Are there any languages that have been designed specifically for this?

Re: Show HN: PRQL in PostgreSQL

#34

Post by quesera »

zoky wrote: post #14

Can someone explain to me why “Show HN” and “Ask HN” posts are always, always in hard-to-read light gray? Is there some cabal that automatically downvotes such posts? Is there something intrinsic to The Algorithm that penalizes such posts? Or do I just have really bad luck and always manage to click through on posts that have gained traction despite having gotten enough downvotes to put them at risk of sudden termina…

They are not penalized, the grey text applies to all text posts.

It's confusing, but greying out is used on HN for a single purpose: to discourage reading (and therefore writing).

Low-quality comments are greyed by downvotes from other users and moderators.

Text posts (including Ask and Show HN) are greyed automatically.

Ask/Show posters are encouraged to post a comment on their own story, and to let that comment rise or fall according to its up/down votes.

Meta-meta: Your comment might be downvoted for being meta to the post. It looks like it has already been "detached" from the comment tree so that it appears at the bottom instead of responding to up/downvotes. This is actually protective of your karma and this conversation. Your question is valid, but it's not germane to the post. If your comment was allowed to float to its normal location, it would be downvoted by others who considered it off-topic.

Re: Show HN: PRQL in PostgreSQL

#35

Post by quesera »

throwaway143829 wrote: post #29
murermader wrote: post #24

Earlier quoted context omitted.

I think I read here on HN some time ago that it is intentionally hard to read to discourage posts with text. I think the reasoning was that posting links to external blogs / websites is usually higher quality than someone creating a quick post on HN. Could be wrong though, just writing this from memory.

HN has some really non-obvious UX, between this and the mysterious green usernames I still don't understand. And the fact that only some users can downvote. Or the weird logic behind which words cannot appear in titles.

Green usernames are new accounts.

Only users with 500 karma can downvote.

Both are mechanisms to dull the potency of new users until they have a chance to learn how HN is expected to work.

This might sound gatekeeping, and it literally is, but consider than HN signup is open and takes 15 seconds with no verification. HN likes the way HN works and these provide simple rate-limits on destructive or oblivious change.

Re: Show HN: PRQL in PostgreSQL

#36

Post by [deleted] »

hans_castorp wrote: post #20
hobs wrote: post #16

Earlier quoted context omitted.

You'd also need a LIMIT or a TOP, and you might need a subquery for that depending on your SQL of choice.

The question was "the longest track per album", so I'd expect one row per album as the result (which is what my query does). But adding a LIMIT would not do that. It might be that the question was "the longest track across all albums" which indeed would require a LIMIT

[deleted]

Re: Show HN: PRQL in PostgreSQL

#37

Post by saganus »

throwaway143829 wrote: post #29
murermader wrote: post #24

Earlier quoted context omitted.

I think I read here on HN some time ago that it is intentionally hard to read to discourage posts with text. I think the reasoning was that posting links to external blogs / websites is usually higher quality than someone creating a quick post on HN. Could be wrong though, just writing this from memory.

HN has some really non-obvious UX, between this and the mysterious green usernames I still don't understand. And the fact that only some users can downvote. Or the weird logic behind which words cannot appear in titles.

Green usernames are for new users.

Re: Show HN: PRQL in PostgreSQL

#38

Post by oulipo »

halayli wrote: post #28
snthpy wrote: post #7

Earlier quoted context omitted.

This comes up every time PRQL makes it onto HackerNews and is a fair question: Short answer: DX Slightly longer answer: Developer productivity and experience, especially for EDA and interactively writing complex analytical queries. Most people that have tried PRQL just find it more convenient to write their analytical queries in it. PRQL compiles to SQL so it can't express anything you can't already do in SQL, but yo…

They can ask chatgpt to generate the SQL query and use the SQL output that everyone is familiar with rather than use an abstraction that is prone to versioning and behavioral changes and will consume everyone else's time to go learn a new language and become profficient in it.

if they need ChatGPT to generate the query (costly and possibly error-prone), then it means that not everyone is familiar with the output...

Re: Show HN: PRQL in PostgreSQL

#39

Post by nwatson »

hosteur wrote: post #6
lkuty wrote: post #3

I don't understand the need for libraries that abstract away SQL when you could just write SQL directly and have full access to the power of the language which is quite rich (recursive CTE, windowing, ... aka Modern SQL). You could also use stored procedures/functions for more complex stuff and e.g. JSON (or native types) to transfer data between the database and the application. Why limit ourselves with a sub-optima…

SQL is incompatible with many types of autocompletion. For example columns in a select statement are not known here you write FROM. This alone justifies PRQL in my opinion.

Jetbrains tools (Datagrip, IntelliJ IDEA, PyCharm) deal well with this if you leave a placeholder column before FROM, and write the FROM part with proper joins. You can go back to the columns and autocomplete goes just fine. You can amend our extended any part and the autocomplete logic adapts well.

Re: Show HN: PRQL in PostgreSQL

#40

Post by quesera »

GordonS wrote: post #13
snthpy wrote: post #7

Earlier quoted context omitted.

This comes up every time PRQL makes it onto HackerNews and is a fair question: Short answer: DX Slightly longer answer: Developer productivity and experience, especially for EDA and interactively writing complex analytical queries. Most people that have tried PRQL just find it more convenient to write their analytical queries in it. PRQL compiles to SQL so it can't express anything you can't already do in SQL, but yo…

> How long would it take you to write the SQL for that? I don't want to appear rude, but unless I'm missing something, this is a pretty simple SQL query, of the kind anyone with mimimal SQL experience could write off the top of their head in seconds. I like the idea of PRQL, but I think a better example is needed to sell it.

I think the logic here is: SQL is hard and most people don't know it well. So PRQL is perhaps easier to learn.

The same logic is applied to TypeScript vs JavaScript. Or C vs assembly. Or Nano vs vim. Etc etc.

It's a quandary though. SQL is clearly difficult for most people to get their heads around. It does require a different way of thinking about data, and you can get by with a minimal SQL knowledge for a long time, especially nowadays with ORMs.

But like so many other things, making the investment is worthwhile and pays off in small and large ways, forever (so far).

Post reply on HN