Live data from Hacker News

Show HN: PRQL 0.2 – a better SQL

github.com

91–100 of 166 posts

Re: Show HN: PRQL 0.2 – a better SQL

#91
post #71

Earlier quoted context omitted.

What is annoying about implementing something like this in a relational database?

It's not straightforward to do polymorphic joins: one common pattern is to have child tables for each case of the union, but there's no integrity constraint such that each parent must only have one child, e.g. CREATE TABLE schools (id SERIAL PRIMARY KEY); CREATE TABLE colleges (id INTEGER NOT NULL REFERENCES schools (id)); CREATE TABLE high_schools (id INTEGER NOT NULL REFERENCES schools (id)); How can you ensure tha…

A combined approach works if want to encode the exclusive constraint:

    CREATE TYPE school_type AS ENUM ('college', 'high_school');
    CREATE TABLE schools (
      id SERIAL PRIMARY KEY,
      type school_type,
      unique (id, type)
    );
    CREATE TABLE colleges (
      id INTEGER NOT NULL,
      type school_type default 'college',
      check (type='college'),
      foreign key (id, type) references school(id, type)
    );
Ya, the syntax is annoying and repetitive. It would be nice if foreign key could be a literal to remove the extra column altogether. e.g.:

    foreign key (id, 'college') references school(id, type)

Re: Show HN: PRQL 0.2 – a better SQL

#93

Earlier quoted context omitted.

What is annoying about implementing something like this in a relational database?

Auto-completion sucks in a lot of sql statements because the table provides all the hints that good autocompletion would need to provide good suggestions. That sounds like a nitpick, but man is it useful when you need it. Notice how the first thing in PRQL is the table declaration. The fact that UPDATE and INSERT have different syntaxes for basically specifying the same mutation operation is pretty dumb.

Have you tried Datagrip?

Re: Show HN: PRQL 0.2 – a better SQL

#94

Earlier quoted context omitted.

If you're willing to sacrifice economics elsewhere, repeating the table's name in the id column is one workaround: from a join b on b.a_id = a.a_id You can even use NATURAL JOIN if you can guarantee that the only fkey/pkey names will overlap between tables. An unreasonable way to achieve that is to put the table name in every column. A more palatable way is to write some clever functions in your schema to scan the in…

If you have identical field names, you can do in sql: Select * from a join b using (a_id) Don't do this in Oracle though, pain follows when you try to touch an a_id column.

You can also do this in PRQL:

    from a
    join b [a_id]
is the equivalent query.

Re: Show HN: PRQL 0.2 – a better SQL

#95
post #25

Why should I use this instead of SQL?

I work on a TUI logfile viewer that uses SQLite as a backend for doing analysis on the log messages (https://lnav.org). However, writing SQL interactively is painful since you can't really provide good auto-complete or preview, which is something I try to provide for most other operations.

The PRQL pipeline syntax would make for a much better experience for lnav since you're able to progressively refine a query without having to jump around. (You've probably noticed that many log services, like Sumologic, already provide a pipeline-style syntax instead of something SQL-like.) The nice thing is that you can simply keep typing to get the results you want and get a preview at each stage. For example, entering "from" and then pressing would make it clear to the program that table-names should be suggested. The program could then show the first few lines of the table. Typing "from syslog_log | filter " and then pressing would make it clear that columns from the syslog_log table should be suggested (along with some other expression stuff). And, then, the preview of the filtered output could be shown.

In the current implementation, pressing just suggests every possible thing in the universe, whether it's appropriate or not. This leaves the poor with not much help after they've typed "SELECT". I find myself having to lookup docs/source to figure out column names or whatever and I wrote the darn thing. Ultimately, I think the analysis functionality just doesn't get used because interactively writing SQL is so user-hostile. So, I'm looking forward to seeing this succeed so that I can integrate it and still be able to use SQLite in the backend.

Re: Show HN: PRQL 0.2 – a better SQL

#96
post #37

I'm surprised that none of the examples on Github or the website deals with join. I eventually found some in the "book" here: https://prql-lang.org/book/transforms/join.html from employees join side:left positions [id==employee_id] turns into SELECT employees.*, positions.* FROM employees LEFT JOIN positions ON id = employee_id I would love to see joins worked into the main learning examples. Without join, the exampl…

I always found that side:left/right should also be expressible as rapport:antecedent/consequent as in propositional logic, rather than limiting these relationships to the geometric representation of Venn diagram. And maybe a shorter alternative might be tie:arm/leg.

I'm not sure if this is a joke, be we actually had a serious an idea to replace side:left/right with nulls_left:true and nulls_right:true

This part of the join operation should be an after thought - just a flag after the central argument of the transform which should be the condition you join over.

Re: Show HN: PRQL 0.2 – a better SQL

#97

I see that the JavaScript package is at [1] and it's implemented by compiling the Rust code to WASM. That should eventually make it pretty easy to run it. It has a typescript definition file, but it looks like it's autogenerated and a bit clunky. You get back a CompileResult and have to call free() explicitly, it seems? That doesn't seem very idiomatic for JavaScript. Also, the links to the documentation and examples…

Thanks a lot — issue added: https://github.com/prql/prql/issues/708

Re: Show HN: PRQL 0.2 – a better SQL

#100

I see that the JavaScript package is at [1] and it's implemented by compiling the Rust code to WASM. That should eventually make it pretty easy to run it. It has a typescript definition file, but it looks like it's autogenerated and a bit clunky. You get back a CompileResult and have to call free() explicitly, it seems? That doesn't seem very idiomatic for JavaScript. Also, the links to the documentation and examples…

That's true - the package is auto-generated using [wasmpak](https://github.com/rustwasm/wasm-pack), that's why TypeScript definitions are clunky. I did the initial prql-js release and I'm actually not sure about the free() issue you are talking about.

We are currently working on compiling it for both Node.js and the browser target, and would be happy to see some advice if you are familiar with WASM!

Post reply on HN