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

101–110 of 142 posts

Re: Show HN: PRQL in PostgreSQL

#101

Post by setr »

quesera wrote: post #40
GordonS wrote: post #13

Earlier quoted context omitted.

> 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…

The hard part of SQL is thinking relationally. This obviously doesn’t do anything to affect that — if they actually thought this, they’d be making the same mistake as SQL itself “the reason business users don’t program is because it’s not english enough”

The problem this is resolving, if it successfully resolves anything at all, is that the SQL language is a mess of random keywords, inconsistent syntax requirements and generates some of the worst error messages known to man. It’s an attempt at making SQL a consistent, simple language — ideally exposing the data model more directly and with less noise

Re: Show HN: PRQL in PostgreSQL

#102

Post by jeroen79 »

ttfkam wrote: post #72
baq wrote: post #12

Earlier quoted context omitted.

> Why limit ourselves with a sub-optimal language be it PRQL? Actually why limit yourself with SQL...? PRQL is a language compiled into SQL and makes certain hard-to-do things in SQL easy purely because it allows to streamline operations which SQL needs CTE joins or whatever hoop jumping to solve. My favorite example which sounds easy but isn't - select the row which is MAX(...).

> Actually why limit yourself with SQL...? Because it's everywhere, has extensive documentation and tutorials, all database tools support it, all relational engines support it, some non-relational engines support it, all programming languages have library support for it, it can be accessed through command line tools as well as graphical interfaces, etc. You think an industry is going to give up 50 years of infrastruc…

I agree, sql is well documented and an industry standard, no need to make it more complex by adding preprocessors that do nothing but change the syntax.

Just bite in and learn proper sql.

Re: Show HN: PRQL in PostgreSQL

#103

Post by Izkata »

quesera wrote: post #35
throwaway143829 wrote: post #29

Earlier quoted context omitted.

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.

> Green usernames are new accounts.

It made sense to me almost immediately, so since people aren't making the connection: https://www.oxfordlearnersdictionaries.com/us/definition/eng...

>5 (informal) (of a person) young and without experience

> The new trainees are still very green.

Re: Show HN: PRQL in PostgreSQL

#104

Post by Izkata »

CuriouslyC wrote: post #21
vendiddy wrote: post #15

Earlier quoted context omitted.

The thing I hate most about SQL is lack of composability. In most languages it's easy to pull out functions. In SQL you end up with a giant hard to comprehend mess. I think the underlying relational concepts in SQL are sound but I'd love to see ideas like PRQL that aim make SQL easier to write and maintain. Stored procedures and functions are nice but don't allow the basic idea of breaking a large query apart into sm…

Your statement about breaking large queries apart is wrong. You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. SQL is just as composable as any other language. The thing that's lacking right now is the tooling for managing/testing/deploying database code. There are solutions out there and the supabase folks have been wor…

> You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly.

Personally I'd go for breaking them into views. IIRC as of around postgres 11-13 they're no longer a barrier for the query planner.

Re: Show HN: PRQL in PostgreSQL

#105

Post by CuriouslyC »

Izkata wrote: post #104
CuriouslyC wrote: post #21

Earlier quoted context omitted.

Your statement about breaking large queries apart is wrong. You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. SQL is just as composable as any other language. The thing that's lacking right now is the tooling for managing/testing/deploying database code. There are solutions out there and the supabase folks have been wor…

> You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. Personally I'd go for breaking them into views. IIRC as of around postgres 11-13 they're no longer a barrier for the query planner.

You are right, views are a good choice in a lot of instances. Functions give you more behavioral flexibility, easy multiple version support (in postgres) and fewer issues with ddl dependencies, but views are semantically clearer, easier to work with and give good usage flexibility.

Re: Show HN: PRQL in PostgreSQL

#106

Post by CuriouslyC »

vendiddy wrote: post #92
CuriouslyC wrote: post #21

Earlier quoted context omitted.

Your statement about breaking large queries apart is wrong. You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. SQL is just as composable as any other language. The thing that's lacking right now is the tooling for managing/testing/deploying database code. There are solutions out there and the supabase folks have been wor…

Do you have any links to a basic example on using CTEs and functions to keep SQL maintainable? I've used CTEs, but I had not tried breaking up an SQL query into functions. Didn't know that was possible! For whatever reason, I feel like I end up with a giant blob of SQL when writing SQL and it's incredibly frustrating.

You can just use chatgpt to rewrite sql with ctes, and extract functions. It's quite good at it, particularly gpt4.

That being said, CTEs are a really good way to write complex queries. They let you tag bits of query with meaningful names, and each thing you tag is accessible to every CTE after it so you can build up an almost imperative data flow by just doing select transforms one after another. That way you're building hard queries from the bottom up rather than the top down.

Re: Show HN: PRQL in PostgreSQL

#109

Post by riku_iki »

OJFord wrote: post #88
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…

In the real world, probably something like: select album_id ,first_value(id order by milliseconds desc) as longest_track_id from tracks group by album_id I agree the PRQL's pretty nice here, but I think such a generalised example (chances you actually want to `select *`?) overstates the advantage.

your query will return just album_id and id, not other track fields

Re: Show HN: PRQL in PostgreSQL

#110

Post by riku_iki »

da_chicken wrote: post #64
orlp wrote: post #45

Earlier quoted context omitted.

QUALIFY is not part of the SQL standard.

I'm pretty sure QUALIFY was added in SQL 2023. Maybe it was only discussed and didn't make it.

more importantly you can run prql on Postgres today, but can't use qualify yet
Post reply on HN