Comments on: SQL: the successful cousin of Haskell

By: Jeff Davis

Jeff Davis — Tue, 18 Oct 2011 07:43:52 +0000

The example you used is invalid per SQL spec, and if you’d like to see a better type system try PostgreSQL. MySQL is notoriously loose with types. I don’t disagree with your point though — there are some important weaknesses in SQL’s type system compared with that of haskell.

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. ]

By: Greg Benison

Greg Benison — Sat, 15 Oct 2011 16:30:33 +0000

Yes, ideas from languages “for theorists only” do have a way of showing up in mainstream contexts, although the source is often not recognized. Here is another example, from the book “Real World Haskell”: “Haskell’s parametric polymorphism directly influenced the design of the generic facilities of the Java and C# languages.”

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)

By: Jeff Davis

Jeff Davis — Tue, 27 Sep 2011 16:56:38 +0000

Yes, I’d certainly like to see more alternatives in this area. A DBMS is seen as a monolith, but in reality there are a few fairly independent pieces that could be offered individually, and I think that could lead to a lot of interesting new ideas and development styles.

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

By: Jeff Davis

Jeff Davis — Tue, 27 Sep 2011 16:54:09 +0000

Agreed.

By: Darren Duncan

Darren Duncan — Tue, 27 Sep 2011 00:09:22 +0000

That’s probably how Muldis D would be the most tightly/efficiently integrated into Postgres, namely at a similar level to how Haskell would. But before that, probably the first practical implementation will be a Muldis D compiler written in Perl where the compiler converted some code to SQL for running inside the DBMS and some code to Perl for running on the client side. I liken it to how LLVM compiles targeting partially the GPU and partially the CPU.

By: Joshua Kugler

Joshua Kugler — Mon, 26 Sep 2011 17:17:31 +0000

Well, PL/Haskell does seem to be in development, but has not yet been officially integrated into PostgreSQL yet.

By: Jeff Davis

Jeff Davis — Sun, 25 Sep 2011 23:59:11 +0000

“Yet another place that an API for bypassing the query parser and speaking directly to the planner/executor would be an opportunity to try some new ideas.”

By: Bay Area Guy

Bay Area Guy — Sun, 25 Sep 2011 20:16:21 +0000

I love how side-effect free languages do such a good job of managing side effects otherwise known as databases.

By: Peter van Hardenberg

Peter van Hardenberg — Sun, 25 Sep 2011 17:35:53 +0000

Yet another place that an API for bypassing the query parser and speaking directly to the planner/executor would be an opportunity to try some new ideas.

By: Jeff Davis

Jeff Davis — Sun, 25 Sep 2011 17:07:32 +0000

“What if GHC compiled some parts of your software to run inside your database engine?”

That’s a particularly interesting question.