[dewey]

Every time I see these layers on top of SQL I think: Just use regular, boring SQL

It will be around for a long time, there's an infinite number of resources and examples for it and if you ever have to onboard someone into your code they don't need to learn something new. You can get pretty far by just using CTEs to "pipeline".

[data_ders]

I'm as big a SQL stan as the next person and I'm also very skeptical anytime anyone says that SQL needs to be replaced.

At the same time, it's challenging that SQL cannot be iteratively improved and experimented upon.

IMHO, PRQL is a reasonable approach to extending SQL without replacing SQL.

But what I'd love to see is projects like Google's zeta-sql [1] and Substrait [2] get more traction. It would provide a more stable, standardized foundation upon which SQL could be improved, which would make the case for "SQL forever" even more strong.

I've blogged about this before [3].

[1]: https://github.com/google/googlesql [2]: https://substrait.io/ [3]: https://roundup.getdbt.com/p/problem-exists-between-database...

[itishappy]

Does anybody just use "regular, boring SQL" in practice though? All queries I have seen are loaded with regex and other non-standard extensions.

Is there even a db vendor that offers full ANSII SQL support? Last I'd checked the answer was no.

[dewey]

In my case I consider Postgres / MariaDB "regular, boring SQL".

[itishappy]

The problem persists, as Postgres and MariaDB use incompatible SQL dialects, right down to (imo) core concepts such as how to specify an automatically generated primary key.

[dewey]

I'm aware of that, but what I meant is that they both extended the SQL standard in a similar way and they will have equivalent higher level features like "regex and other non-standard extensions" even if they are not 100% drop-in replacements.

[itishappy]

Understood. My point is that the underlying concepts are consistent, but the syntax differs between vendors. This largely applies to PRQL as well. Admittedly slightly moreso, but if I already have to learn a new SQL dialect to use postgres, I might not mind learning a nicer one.

[kubb]

Complex queries in SQL can quickly get out of control.

The fact that you need to replicate the same complex expressions in multiple values that you select or multiple parts of a where clause is bad enough.

That there’s no way to pipe the result of a query into another query is just adding insult to injury. (Just create a custom view bro).

But if technology competed in quality and not in vendor lock in, we wouldn’t have to deal with C++ or JavaScript.

[tomjakubowski]

DuckDB's "friendly SQL" variant fixes some of these little problems with SQL, including giving the ability to use a column alias in WHERE clauses.

https://duckdb.org/docs/stable/sql/dialect/friendly_sql