5 ms·

It doesn’t compose properly, lacks type safety, you have to codegen your statements in the application anyways and is generally an utter bitch to do so because

by setr 4y ago

It doesn’t compose properly, lacks type safety, you have to codegen your statements in the application anyways and is generally an utter bitch to do so because it’s horrifically inconsistent (and doesn’t compose properly). You can dump everything into stored procs and functions, but now you get worthless compiler errors, indirect version control at best, and really your whole tooling support is reverted to the 80’s. It’s a pretty shit language — its just the only one we get to have, and the value of what it interfaces with (the RDBMS itself, ACID and the relational algebra) is… invaluable. You can’t get away with not knowing it, and it’s generally dumb to avoid it (because you’re then avoiding the glory behind it) but as a language it’s basically COBOL-tier.

crabbone 4y ago
> It doesn’t compose properly Stored procedures? > lacks type safety How so? Can you give some examples? I have no idea what this is even about. > you have to codegen your statements Never happened to me. Not in any capacity that I would feel like this was a burden. The only cases where I needed to generate SQL code were some fuzzing tests intended to figure out problems with database performance, s.a. feeding a bunch of generated SQL to pgbench to see what may cause the database to slow down / use too many resources. This seems very strange in an application that is simply using SQL database rather than trying to do something weird with it (eg. testing performance). SQL is a very high-level language, which means you don't need to do as much code generation compared to, say, Assembly or even Java. I do see that people do this when they use ORM, but this is a self-inflicted pain. They shouldn't have been doing ORM to begin with. > get worthless compiler errors From what? Are you talking about writing SQL functions (eg. in Java) and then using them from SQL (eg. Oracle)? This doesn't sound like a SQL problem, more like Java compiler problem... But, yeah, I can see how this is a complication and an inconvenient thing to do, so, if that's what you mean, I'm generally with you on this one. Well, I think that the benefits are still worth doing this. > whole tooling support is reverted to the 80’s. Again, I don't see the connection. But, even if it was so... what's the problem? You get to work with an old and reliable technology, with decades of knowledge and experience to support it. And it's not like it died in the 80's. Tons of effort is being invested into this technology, it's amongst the first to get updates and integrations with new hardware and system capabilities (eg. vectorized ISAs support, even GPU access, bet you that when "smart SSD" become common enough, SQL databases will be the first to support them). What's not to like? This is like complaining about C compilers for being "old tech"... for all that's wrong with C (compilers), being old is not one of those things. > It’s a pretty shit language If you were honest, you'd write it like this: "I don't like it". And, well, you are allowed not to like whatever you want. It's subjective, and completely up to you. It just has less of a convincing power. But, really, this is your entire argument...
- ttfkam 4y ago
  Yeah, the "lacks type safety" comment threw me too. SQL has some of the most rigid type safety in my daily interactions in computing. • "Exactly one" • "Optional" • "Text but matching this pattern" • "A 16-bit integer from 1 to 1000" • "Many to many without any duplicates" • "A unique combination of id and a time range" • "This field can be NULL but only if this other field is NOT NULL"
  - yencabulator 4y ago
    Now store a 64-bit unsigned integer in Postgres.
    - anarazel 4y ago
      CREATE DOMAIN unsigned_64bit_int AS numeric CONSTRAINT range CHECK (VALUE >= 0 AND VALUE < 2^64 AND round(VALUE) = VALUE);
    - crabbone 4y ago
      Use bigint with check-between constraint? Maybe inconvenient, but not impossible... but if this is the kind of problem you have, then, try in your favorite language to create integers that are 63 bit long or 65, and see how it goes? Looks like the comparison won't be in that language's favor.
      - yencabulator 4y ago
        Postgres bigint is a signed 64-bit integer, not an unsigned one. https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-NUMERIC-TABLE https://www.postgresql.org/docs/current/datatype-numeric.htm... Trying to use it to store the full range of unsigned values would mean awkward math everywhere, to convert between the two ranges. Lots of software uses uint64s, for e.g. as identifiers handed out by some API, and not being able to store them conveniently definitely hurts.
    - ttfkam 4y ago
ttfkam 4y ago
SQL, as a set-oriented language, composes just fine. • views • CTEs • temporary tables • set-returning functions It will not compose like an OO language or like a functional language because it isn't one of those. It's set-oriented. This is the biggest hangup I've seen from folk who hate SQL: mistaking it for something it isn't, never was, and was never intended to be given its problem domain.

by setr 4y ago

crabbone 4y ago

> It doesn’t compose properly Stored procedures? > lacks type safety How so? Can you give some examples? I have no idea what this is even about. > you have to codegen your statements Never happened to me. Not in any capacity that I would feel like this was a burden. The only cases where I needed to generate SQL code were some fuzzing tests intended to figure out problems with database performance, s.a. feeding a bunch of generated SQL to pgbench to see what may cause the database to slow down / use too many resources. This seems very strange in an application that is simply using SQL database rather than trying to do something weird with it (eg. testing performance). SQL is a very high-level language, which means you don't need to do as much code generation compared to, say, Assembly or even Java. I do see that people do this when they use ORM, but this is a self-inflicted pain. They shouldn't have been doing ORM to begin with. > get worthless compiler errors From what? Are you talking about writing SQL functions (eg. in Java) and then using them from SQL (eg. Oracle)? This doesn't sound like a SQL problem, more like Java compiler problem... But, yeah, I can see how this is a complication and an inconvenient thing to do, so, if that's what you mean, I'm generally with you on this one. Well, I think that the benefits are still worth doing this. > whole tooling support is reverted to the 80’s. Again, I don't see the connection. But, even if it was so... what's the problem? You get to work with an old and reliable technology, with decades of knowledge and experience to support it. And it's not like it died in the 80's. Tons of effort is being invested into this technology, it's amongst the first to get updates and integrations with new hardware and system capabilities (eg. vectorized ISAs support, even GPU access, bet you that when "smart SSD" become common enough, SQL databases will be the first to support them). What's not to like? This is like complaining about C compilers for being "old tech"... for all that's wrong with C (compilers), being old is not one of those things. > It’s a pretty shit language If you were honest, you'd write it like this: "I don't like it". And, well, you are allowed not to like whatever you want. It's subjective, and completely up to you. It just has less of a convincing power. But, really, this is your entire argument...

ttfkam 4y ago
Yeah, the "lacks type safety" comment threw me too. SQL has some of the most rigid type safety in my daily interactions in computing. • "Exactly one" • "Optional" • "Text but matching this pattern" • "A 16-bit integer from 1 to 1000" • "Many to many without any duplicates" • "A unique combination of id and a time range" • "This field can be NULL but only if this other field is NOT NULL"
- yencabulator 4y ago
  Now store a 64-bit unsigned integer in Postgres.
  - anarazel 4y ago
    CREATE DOMAIN unsigned_64bit_int AS numeric CONSTRAINT range CHECK (VALUE >= 0 AND VALUE < 2^64 AND round(VALUE) = VALUE);
  - crabbone 4y ago
    Use bigint with check-between constraint? Maybe inconvenient, but not impossible... but if this is the kind of problem you have, then, try in your favorite language to create integers that are 63 bit long or 65, and see how it goes? Looks like the comparison won't be in that language's favor.
    - yencabulator 4y ago
      Postgres bigint is a signed 64-bit integer, not an unsigned one. https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-NUMERIC-TABLE https://www.postgresql.org/docs/current/datatype-numeric.htm... Trying to use it to store the full range of unsigned values would mean awkward math everywhere, to convert between the two ranges. Lots of software uses uint64s, for e.g. as identifiers handed out by some API, and not being able to store them conveniently definitely hurts.
  - ttfkam 4y ago

ttfkam 4y ago

SQL, as a set-oriented language, composes just fine. • views • CTEs • temporary tables • set-returning functions It will not compose like an OO language or like a functional language because it isn't one of those. It's set-oriented. This is the biggest hangup I've seen from folk who hate SQL: mistaking it for something it isn't, never was, and was never intended to be given its problem domain.