3 ms·

> I still would like that SQL read a bit more set-theoretic, if less English-like. It would make it less quirky and more composable. I wish that it didn't intr

> I still would like that SQL read a bit more set-theoretic, if less English-like. It would make it less quirky and more composable. I wish that it didn't introduce an incomprehensible ternary logic for null handling. SQL with algebraic data types would be amazing.

nine_k 8y ago
Nulls are facts of life. I wonder how they could be succinctly represented in a query language. Something like the `?` operator in C# / Kotlin?
- andrewflnr 8y ago
  That would be an improvement. I'd rather have proper algebraic sum types, though (Option or Optional in languages like Haskell, OCaml, et al). They're really useful for all kinds of stuff. Perfectly representing missing values is almost a fringe benefit.
  - darksaints 8y ago
    Not only would algebraic sum types be awesome, but if user-defineable they could eliminate so much of the ambiguity in how nulls are practically used in SQL. People often say that null just means unknown but that is a bug-causing simplification. In reality, null could mean unknown, but it could also mean not yet known, uninitialized, missing, impossible, uncomputable, join conditions not met, or hundreds of other things. And sum types would be extremely useful even outside of null handling...there are thousands of reasons why more and more modern languages are designed with sum types. Not only would sum types be extremely helpful but it would also be awesome to have a standard for product types. As it stands, some implementations have them but they are clunky, and others you have to resort to just using multiple columns, which is pretty bad for composability, bug-ridden, and leads to behavior that is almost like Hungarian notation in order to maintain unique column naming. For example: create table foo( start zoneddatetime, end zoneddatetime ... ); versus create table foo( start_time timestamp, start_tz timezone, end_time timestamp, end_tz timezone ... ); (timestamptz is not an acceptable substitute...it doesn't store timezone)
rosser 8y ago
SQL's null really isn't incomprehensible. It just means "unknown". It's broadly like "undefined" in js.
- setr 8y ago
  3VL stuffed into a boolean logic system is what’s incomprehensible.
crgwbr 8y ago
I assume you mean how null has to be compared with the IS operator instead of equality? I’ve wondered the same thing, but would making Null==Null have some strange consequences for left join operations? You could pretty easily and unintentionally return the Cartesian product of the two tables. Requiring a different operator for comparing to bill prevents that.
- darksaints 8y ago
  Having optional types (or algebraic sum types) would eliminate this as well has hundreds of other sources of bugs, and would eliminate the 3 valued logic that few users truly understand.

nine_k 8y ago

Nulls are facts of life. I wonder how they could be succinctly represented in a query language. Something like the `?` operator in C# / Kotlin?

andrewflnr 8y ago
That would be an improvement. I'd rather have proper algebraic sum types, though (Option or Optional in languages like Haskell, OCaml, et al). They're really useful for all kinds of stuff. Perfectly representing missing values is almost a fringe benefit.
- darksaints 8y ago
  Not only would algebraic sum types be awesome, but if user-defineable they could eliminate so much of the ambiguity in how nulls are practically used in SQL. People often say that null just means unknown but that is a bug-causing simplification. In reality, null could mean unknown, but it could also mean not yet known, uninitialized, missing, impossible, uncomputable, join conditions not met, or hundreds of other things. And sum types would be extremely useful even outside of null handling...there are thousands of reasons why more and more modern languages are designed with sum types. Not only would sum types be extremely helpful but it would also be awesome to have a standard for product types. As it stands, some implementations have them but they are clunky, and others you have to resort to just using multiple columns, which is pretty bad for composability, bug-ridden, and leads to behavior that is almost like Hungarian notation in order to maintain unique column naming. For example: create table foo( start zoneddatetime, end zoneddatetime ... ); versus create table foo( start_time timestamp, start_tz timezone, end_time timestamp, end_tz timezone ... ); (timestamptz is not an acceptable substitute...it doesn't store timezone)

rosser 8y ago

SQL's null really isn't incomprehensible. It just means "unknown". It's broadly like "undefined" in js.

setr 8y ago
3VL stuffed into a boolean logic system is what’s incomprehensible.

crgwbr 8y ago

I assume you mean how null has to be compared with the IS operator instead of equality? I’ve wondered the same thing, but would making Null==Null have some strange consequences for left join operations? You could pretty easily and unintentionally return the Cartesian product of the two tables. Requiring a different operator for comparing to bill prevents that.

darksaints 8y ago
Having optional types (or algebraic sum types) would eliminate this as well has hundreds of other sources of bugs, and would eliminate the 3 valued logic that few users truly understand.