31–40 of 214 posts
We use SQL for a lot of things, almost all of them implementation of customized business rules. When attempting to develop a business rule that needs to manifest as a single SQL query, your brain is forced to work in a very particular crystalline way. Many business rules are defined in procedural terms at requirements time, so having a way to implement them in the same could be beneficial.
Earlier quoted context omitted.
I like it too. You can also alias them easily from e=employees join p=positions (e.id==p.employee_id)
positions p is a SQL alias. Was that too difficult?
If the main complaint people have about SQL is that you can't swap SELECT, FROM and WHERE, then that's pretty good for a language designed in the 70s. This, by contrast, looks like it has a bunch of random line noise for syntax. Why on earth should I like this: `join side:left p=positions (p.id==employees.employee_id)` better than this: `LEFT JOIN positions AS p ON p.id = employees.employee_id` ?
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?
it seems like any SQL parser could let you put FROM first and solve a lot of the annoyances of SQL
This must not be missing here then: "I don't want to learn your garbage query language" [1] [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-ga...
Our goal for PRQL is a great language to integrate with & build on. So we don't have N languages for N databases. Because PRQL will always be open-source, and won't ever have a commercial product, we think that's much more feasible than a DB-specific or product-specific language.
(PRQL dev here)
Pretty cool and responsive. I'll go take it up for a spin.
Just a heads up that Prefect integration link on the landing page doesn't work - 404. This is the one I was interested in!
(PRQL dev here)
>declarative An admirable ideal, but declarative languages always seem to devolve towards some frankenstein imperative/declarative hybrid. We need to stop going down this path and embrace Pulumi's pattern: use existing general purpose imperative languages to generate a declarative structure. Instead, people try to take their not-mature declarative language and fit a weird general purpose language inside it. EDIT>> I'…
Could you provide a reference that elaborates on "Pulumi's pattern"?
Just a heads up that Prefect integration link on the landing page doesn't work - 404. This is the one I was interested in!
The correct link is the following: https://prql-lang.org/book/project/integrations/prefect.html
TBH, that one is not much of an integration yet. It essentially boils down do.
$ pip install prql-python
import prql_python
PostgresExecute.run(..., query=prql_python.compile(prql))
Disclaimer: I'm a PRQL contributor.