3 ms·

> Rust hasn't swept the world yet and it helps prevent real bugs and security issues. As the inventor of the relational model has written about extensively, an

> Rust hasn't swept the world yet and it helps prevent real bugs and security issues. As the inventor of the relational model has written about extensively, and as you have no doubt came to realize yourself if you've used SQL for more than a few minutes, a different query language could have prevented a whole lot of real bugs too. SQL also has its fair share of security problems that are only prevented by telling developers to be careful. Rust will never sweep the world, of course, because there is no reason to choose a single language in the application space. Something sweeping the world tells that you royally screwed up the execution environment. But it is a viable contender, despite being no different than C in any meaningful way (clearly you don't see bug/security issue prevention as being meaningful). > despite it's quirks, that there doesn't exist a language better enough to make it worth replacement. As you know, Postgres went in the opposite direction, eventually switching to SQL. A DMBS – one which is probably the second most popular DMBS in existence at that – completely upending what query language it supports is not without precedent. What do you think it was about SQL that made it substantially better to justify the change?

wvenable 2y ago
You seem to have my point backwards. It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL. Ultimately, what made Postgres interesting wasn't the query language. > a different query language could have prevented a whole lot of real bugs too. SQL also has its fair share of security problems that are only prevented by telling developers to be careful. I can't think of an example where one of these newer query languages actually solve bugs in the way that Rust does with the borrow checker. Slightly better syntax may prevent bugs but no where near in the same way. I don't find SQL particularly bug-inducing -- it's mostly just annoying.
- randomdata 2y ago
  > It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL. You seem to have your own point backwards, unless you have failed to make one. The premise you gave, at least as I understand it, is that there is no reason to put in the effort in moving away from SQL because nothing else is substantially better. So, by the same token, unless SQL was substantially better than QUEL, there should have been no reason for Postgres to put in the effort to make the same transition. Which implies that SQL was substantially better. The question was: In what way? > I can't think of an example where one of these newer query languages actually solve bugs Perhaps because you are getting hung up on newer? They need not even be newer. The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha. [1] Problem might not be the right framing, but I lack a better word. There is no problem if you write perfect queries every single time. But, like C, it opens opportunities for making mistakes that could have been made impossible with a different design.
  - wvenable 2y ago
    > Which implies that SQL was substantially better. That is begging the question. It doesn't have to be selected because it's substantially better. If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option. > The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha. What was that?
    - randomdata 2y ago
      > If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option. There is a good case to be made that, for better or worse, single page applications (SPAs) are the more popular/standard option as compared to generated HTML, even if roughly equivalent, for web applications. Does this mean that HN is making a mistake in not adopting that model? You did say always. It is not like Postgres was a new project and they simply had to pick something. It had been with us for a decade before deciding to take the SQL direction. It could have much more easily continued down the path it was already going. There was a significant amount of cost involved to make the switch. When Postgres was first created there was no clear winner, but by the time the switch was made it was apparent that SQL was becoming the more popular choice, I'll give you that. Is that the only reason for the move? Thing is, I'm not sure SQL is even all that popular nowadays. I expect the vast majority of DBMS queries are only using SQL as a compiler target, more likely being written in a class of languages often referred to as ORMs. By your logic, databases should be adopting what best aligns with that programming model rather than clinging to SQL. You did say always, after all. Granted, there are some half-hearted attempts to do exactly that by some DBMS vendors (e.g. recent Oracle releases support "3D" queries that return JSON structures rather than relations, more closely matching language semantics), but not in any way that appears to be all that serious and definitely not in any kind of consorted way. It seems the SQL crowd still can't get over that there might be an alternative. In fact, often they can't even envision anything other than SQL being possible. I don't know how many times I've heard someone claim that SQL is some kind of fundamental mathematical property. > What was that? The most common SQL bug I see in my travels can be distilled down to something like: SELECT t1.* FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id To be fair, I'm not sure the bug would go unnoticed with such a simple query - where one is able to keep the entire mental model in their head. But consider the basis of that query expanded into something complex, where one will struggle to maintain all of the minute details in active memory. That is where I see bugs be introduced all the time, even by experienced developers. A different design – including the originally designed database query language – has proven to eliminate this class of bug.

wvenable 2y ago

You seem to have my point backwards. It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL. Ultimately, what made Postgres interesting wasn't the query language. > a different query language could have prevented a whole lot of real bugs too. SQL also has its fair share of security problems that are only prevented by telling developers to be careful. I can't think of an example where one of these newer query languages actually solve bugs in the way that Rust does with the borrow checker. Slightly better syntax may prevent bugs but no where near in the same way. I don't find SQL particularly bug-inducing -- it's mostly just annoying.

randomdata 2y ago
> It's not that SQL is substantially better than QUEL, it's that QUEL was not substantially better than SQL. You seem to have your own point backwards, unless you have failed to make one. The premise you gave, at least as I understand it, is that there is no reason to put in the effort in moving away from SQL because nothing else is substantially better. So, by the same token, unless SQL was substantially better than QUEL, there should have been no reason for Postgres to put in the effort to make the same transition. Which implies that SQL was substantially better. The question was: In what way? > I can't think of an example where one of these newer query languages actually solve bugs Perhaps because you are getting hung up on newer? They need not even be newer. The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha. [1] Problem might not be the right framing, but I lack a better word. There is no problem if you write perfect queries every single time. But, like C, it opens opportunities for making mistakes that could have been made impossible with a different design.
- wvenable 2y ago
  > Which implies that SQL was substantially better. That is begging the question. It doesn't have to be selected because it's substantially better. If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option. > The most glaring bug-inducing "problem"[1] of SQL was already recognized and solved by the original database querying language, Alpha. What was that?
  - randomdata 2y ago
    > If you have two things that are roughly equivalent, it's always better to pick the more popular/standard option. There is a good case to be made that, for better or worse, single page applications (SPAs) are the more popular/standard option as compared to generated HTML, even if roughly equivalent, for web applications. Does this mean that HN is making a mistake in not adopting that model? You did say always. It is not like Postgres was a new project and they simply had to pick something. It had been with us for a decade before deciding to take the SQL direction. It could have much more easily continued down the path it was already going. There was a significant amount of cost involved to make the switch. When Postgres was first created there was no clear winner, but by the time the switch was made it was apparent that SQL was becoming the more popular choice, I'll give you that. Is that the only reason for the move? Thing is, I'm not sure SQL is even all that popular nowadays. I expect the vast majority of DBMS queries are only using SQL as a compiler target, more likely being written in a class of languages often referred to as ORMs. By your logic, databases should be adopting what best aligns with that programming model rather than clinging to SQL. You did say always, after all. Granted, there are some half-hearted attempts to do exactly that by some DBMS vendors (e.g. recent Oracle releases support "3D" queries that return JSON structures rather than relations, more closely matching language semantics), but not in any way that appears to be all that serious and definitely not in any kind of consorted way. It seems the SQL crowd still can't get over that there might be an alternative. In fact, often they can't even envision anything other than SQL being possible. I don't know how many times I've heard someone claim that SQL is some kind of fundamental mathematical property. > What was that? The most common SQL bug I see in my travels can be distilled down to something like: SELECT t1.* FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id To be fair, I'm not sure the bug would go unnoticed with such a simple query - where one is able to keep the entire mental model in their head. But consider the basis of that query expanded into something complex, where one will struggle to maintain all of the minute details in active memory. That is where I see bugs be introduced all the time, even by experienced developers. A different design – including the originally designed database query language – has proven to eliminate this class of bug.