Live data from Hacker News

It's not you, it's SQL

stack.convex.dev

1–10 of 84 posts

Re: It's not you, it's SQL

#3
post #2

> Tab! Tab! Tab! PostgreSQL demonstrates its field autocomplete feature. SELECT preceeding FROM is such a thorn in the side. :(

I wish SQL did not require a comma between items after the SELECT and before the FROM. We don't need commas in between joins. I feel like someone could write a way to parse queries so that it isn't needed.

Can you imagine how much time and effort that would save people?

Edit: You do need commas in ORDER BYs, that slipped my mind when typing out this pet peeve of mine.

Re: It's not you, it's SQL

#4
post #2

> Tab! Tab! Tab! PostgreSQL demonstrates its field autocomplete feature. SELECT preceeding FROM is such a thorn in the side. :(

I wish SQL did not require a comma between items after the SELECT and before the FROM. We don't need commas in between joins. I feel like someone could write a way to parse queries so that it isn't needed. Can you imagine how much time and effort that would save people? Edit: You do need commas in ORDER BYs, that slipped my mind when typing out this pet peeve of mine.

But, what would the token be? Where clauses are separated by AND and OR. Order by are separated by commas. Joins are separated by JOIN, INNER JOIN, AND, etc. The parser knows where the WHERE clauses are because they see the WHERE token.

Re: It's not you, it's SQL

#5
post #2

> Tab! Tab! Tab! PostgreSQL demonstrates its field autocomplete feature. SELECT preceeding FROM is such a thorn in the side. :(

I wish SQL did not require a comma between items after the SELECT and before the FROM. We don't need commas in between joins. I feel like someone could write a way to parse queries so that it isn't needed. Can you imagine how much time and effort that would save people? Edit: You do need commas in ORDER BYs, that slipped my mind when typing out this pet peeve of mine.

I'd be happy if it just accepted a dangling comma so you can swap your columns around freely without causing a syntax error

Re: It's not you, it's SQL

#6
>> Unlike SELECT, these operations don't feature JOINs or subqueries or any other magic that brings together tables.

This is a false statement. Both INSERT and UPDATE support JOINs and subqueries / CTEs. At least according to the standard - not every engine implementing them is another story.

Re: It's not you, it's SQL

#7
The article presents the move from the old, doddering SQL to the newer, better NoSQL - but the hierarchical database model actually _predate_ SQL. The first databases like IBM's IMS were hierarchical a lot like Mongo is: Codd was actually trying to address the problems with that model when he created the relational model.

Re: It's not you, it's SQL

#9
post #6

>> Unlike SELECT, these operations don't feature JOINs or subqueries or any other magic that brings together tables. This is a false statement. Both INSERT and UPDATE support JOINs and subqueries / CTEs. At least according to the standard - not every engine implementing them is another story.

> not every engine implementing them is another story

Which don't? I'd have assumed anything inside of `SELECT`'s `FROM` would be allowed inside of `INSERT` and `UPDATE`.

Or maybe you're not saying you know there are implementations that have these restrictions just that any random implementation might not be there (yet).

Re: It's not you, it's SQL

#10
On the other side of things, it's interesting to see SQL engines innovating. Though the only one I can name for sure is DuckDB: https://duckdb.org/2022/05/04/friendlier-sql.html.

Have other implementations done anything for making queries easier (that don't involve requiring an IDE or anything, so just query language innovations)?

Edit: Not query language innovations but ClickHouse and Snowflake's "standard library" of builtin functions just keep getting better and better. Once I saw `parseDateTimeBestEffort` in ClickHouse I wanted that everywhere...

Post reply on HN