I believe that type strictness in SQL brings more confidence to the answers given by the system. What you don’t want is for your data to bring about unexpected edge cases, and the type constraints help a great deal with that (e.g. if the column is of type “integer”, you know you’re not going to get “9foobar”).

Unfortunately, NULL semantics really destroy this property of SQL because they introduce exactly the kind of edge cases that cause errors, and they propagate through the query making subtle errors more likely. For instance, consider the query: SELECT dealer, sum(sales) FROM dealer_sales GROUP BY dealer HAVING sum(sales) < 100000;. What that query should do is return under-performing dealers (those with low sales). But if a certain dealer no sales at all, the sum() returns NULL, and thus the dealer is not returned (because any comparison with NULL is NULL). However, the answer will look right — it’s just missing some of the dealers. That kind of subtle problem is something that haskell could easily catch through exhaustive pattern matching over a Maybe.

[ I think that this thread has been closed for comments (which I have to do to avoid too much spam), but I'll see if I can figure out how to re-open it. ]

Thanks for pointing out the interesting analogies between SQL and Haskell. I’d disagree, though (see example below), that SQL is as strict as Haskell is about types – few things are. What would true type strictness in SQL expressions do to (for?) the language?

mysql> select (“9foobar” = 9);
+——————+
| (“9foobar” = 9) |
+——————+
| 1 |
+——————+
1 row in set (0.00 sec)

Giving a talk on this topic at PG WEST this week.

To prevent “gaps” is a little tricky, but perhaps it can be done with triggers, row-level locks, and exclusion constraints. In a way, it’s kind of like a foreign key into the same table. The tricky part is the initial condition for a group where there is no other period to “connect” with.

I’ll think about it a little more and write up a blog post about it.

+1