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

131–140 of 142 posts

Re: Show HN: PRQL in PostgreSQL

#131

Post by andyferris »

dangoldin wrote: post #55
dvdkon wrote: post #48

Damn, now my bachelor's thesis will be less unique :) I'm working on a new language that compiles directly to Postgres' post-analysis structs. It's working out pretty well so far, but my chosen "universal set" (aggregation/array/subquery/... as one thing) semantics are sometimes a pain to encode.

Not to change your direction but something I've been toying around is being able to support Algebraic types when defining tables. That way you can offload a lot of the error checking to the database engine's type system and keep application code simpler.

Sounds wonderful. I actually think this is the highest value thing anyone could contribute to Postgres (assuming it could handle foreign key constraints inside the sum types).

Re: Show HN: PRQL in PostgreSQL

#134

Post by buremba »

staticautomatic wrote: post #56
buremba wrote: post #52

Earlier quoted context omitted.

Hmm, I would think that LLM helps adoption for the semantic layers such as PRQL, Malloy, and dbt since it's possible to generate/validate/iterate 5 lines of PRQL compared to 25 lines of SQL but considering none of them widely adopted yet, you might indeed be correct in a way that LLM makes it harder for the new tools to gain adoption by helping you to suffer less from the verboseness of SQL.

It’s a tough call. I run a small analytics team and am starting to train some analysts to code. Just the other day I basically told one of my reports to focus on learning Python and let ChatGPT teach him SQL by example because I think it’ll be easier to grok the explanations. Now I’m looking at PRQL and Malloy and asking myself if it’s really a path I should send them down, and I’m not sure it’s a good idea.

I just tried ChatGPT to generate some Malloy snippets and compared to SQL, it’s very basic. It’s probably not a huge lift to teach it the library by scanning the docs but still the reasoning with SQL is much sophisticated given that there are tons of training data.

Re: Show HN: PRQL in PostgreSQL

#135

Post by RedCrowbar »

ttfkam wrote: post #116
canadiantim wrote: post #70

Earlier quoted context omitted.

Would love to see EdgeQL become adopted beyond EdgeDB. I don't like the vendor lock-in with EdgeDB, but I think they're doing great work

"A jaw-dropping amount of effort has been spent attempting to bridge the gap between the relational paradigm of SQL and the object-oriented nature of modern programming languages. EdgeDB sidesteps this problem by modeling data in an object-relational way." All the best to the team. I however truly hope this isn't the direction the industry moves toward. I thought we learned our lesson from MongoDB. I still believe da…

EdgeDB is NOT an object store. It is "relational model enhanced" instead where a set is a fundamental building block [1] so not just relations are sets, but attributes can be sets also.

[1] https://www.edgedb.com/docs/edgeql/sets#ref-eql-everything-i...

Re: Show HN: PRQL in PostgreSQL

#136

Post by zokier »

Sammi wrote: post #129
mt_ wrote: post #122

Is PRQL faster than the standard query model?

PRQL compiles to SQL. Why would it be faster? The intention is rather for it to be simpler, as it uses a linear direction of data handling. SQL jumps back and forth with its order of operations and can be confusing in this way. PRQL also has a more modern syntax that reuses more universal concepts with fewer keywords to learn. In contrast to SQL which has a unique keyword, syntax, and behavior for everything.

I think more relevant question would be is naive idiomatic prql faster than naive idiomatic sql? Of course you can tune any sql to hell and back, but the chances for some non-expert developer to land on anything nearly optimal sql are not so great. So if prql helps non-experts to get decent perf easier, I'd chalk that up as a win, and that is not so outlandish goal anymore.

Re: Show HN: PRQL in PostgreSQL

#137

Post by quesera »

lowercased wrote: post #66
quesera wrote: post #40

Earlier quoted context omitted.

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…

> making the investment is worthwhile and pays off in small and large ways And... 'making the investment' takes time, and means that time is not able to be invested someplace else. If the majority of your job is writing SQL or similar (data access, etc) then sure - yes, learn more of those tools. Some folks have a wider range of responsibilities that means you have to decide what to make more time investments in, and…

Eh, sure. Some people are not developers or don't work with systems.

But 20 hours spent learning SQL pays off for a lifetime. Most people watch more hours of TV than that per week.

We all make our choices, but very very few people could not find 20 hours somewhere in their lives, with zero net loss.

Re: Show HN: PRQL in PostgreSQL

#138

Post by setr »

ttfkam wrote: post #120
setr wrote: post #101

Earlier quoted context omitted.

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

I prefer "thinking in sets". Either way, folks try to map objects and structs to their databases (I blame ORMs personally) when the analogy just isn't so. It's like translating French to English word by word and wondering why folks have trouble understanding you. As for SQL being too much like English, making the syntax closer to a general purpose functional programming language isn't necessarily an improvement in my…

> making the syntax closer to a general purpose functional programming language

It’s more about having a consistent, predictable and simple language. Being more functional-like or imperative-like or declarative-like or whatever is just a byproduct. I suppose LISP is the extreme of that goal, and probably too extreme, but SQL itself is on the other end, with every clause and function running its own subsyntax and special cases. I believe I’ve read the ANSI SQL standard defines something like 1700 terminals — it’s absolutely absurd. And of course every database extends that standard arbitrarily with a slew of new keywords.

There’s a reason every RDBMS can only report errors like “syntax error on line 1: ” and it’s not because the devs are completely incompetent

Re: Show HN: PRQL in PostgreSQL

#139

Post by qazxcvbnm »

Off-topic: does anyone know of SQL-to-SQL optimisers or simplifiers? I understand that databases themselves have query-optimisers, and that's not what I'm talking about - I work with generated query systems and SQL macro systems that make fairly complex queries quite easy to generate, but often times come up with unnecessary joins/subqueries etc.

PostgreSQL's query-optimiser does handle these cases quite well for me once I explain and add the appropriate indexes, yet complex source queries carry undiscountable costs (longer planning times, missed optimisations e.g. predicate pushdowns).

I find myself needing to mechanically transform and simplify SQL every now and then, and it hardly seems something out of reach of automation, yet somehow I've never been able to find software that simplifies and transforms SQL source-to-source. When I look, I only find optimisers for SQL execution plans. It's a bit hard to believe that such a thing doesn't exist, given how significant the SQL ecosystem is.

Re: Show HN: PRQL in PostgreSQL

#140

Post by [deleted] »

dewey wrote: post #10
hans_castorp wrote: post #9

Earlier quoted context omitted.

> How long would it take you to write the SQL for that? select distinct on (album_id) * from tracks order by album_id, milliseconds desc;

With the additional benefit that resources about SQL are everywhere and every question has been answered already multiple times. On top of that you are most likely to encounter SQL at a job than PRQL.

[deleted]
Post reply on HN