Hacker News Reader

Comment by PhineasRex | Hacker News Reader

There's no real reason you can't have sum types in a relational database, this just goes back to our current crop of RDBMSs being quite old and predating the current emphasis on strong typing. I suspect a modern relational database with an easier way define complex types (not writing a plugin) would be very popular, but the amount of work required to make something like that is immense

View on HN

That matches my intuition. The more surprising thing is that this doesn't seem to be talked about very much. I've literally never heard anyone else advocate for a relational database with support for sum types (I'm sure they exist) which has caused a lot of introspection about whether or not there's something about RDBMSs that I just don't understand.

it came and went, postgres and sql server were (and still are) referred to as "object-relational" because of their support for rich user-defined complex types. it's just not that practical real-world because we tend to start with first normal form which complex types violate naturally.

> whether or not there's something about RDBMSs that I just don't understand

perhaps if you consider the entire result of some query to imply the type of the thing being modeled rather than any given table or cell, then it's more obvious that the basic types supported aren't much of a limitation? afterall you can always include a "type" indicator (or project one from a more sophisticated relational model).

Normal form supports complex product types just fine. A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object, and of course a result set is a list.

But I’m not talking about product types, complex or otherwise. I’m talking about sum types (also known as Algebraic Data Types).

> A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object

if you're already thinking of it that way then it's a small jump to the result set as a set, that can participate in a union - and there's your sum type. add or project a type indicator and it's literally a tagged union.

That's not type safe.

honestly I don't see how it's not - do you want to be able to union an int with a float or something? there's sql_variant or you can make your own type but that's pretty gross, violates 1NF, and is the opposite of type-safety IMO

Tagged unions as you describe are dynamic types. With a fair amount of effort, a SQL query can perhaps use the tag column to make sense of the other columns in the union at runtime, but the type system doesn't have access to that information. You can get part of the way there with constraints, but it's tedious and incomplete.

Reply on news.ycombinator.com