[throwaway894345]

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

[gfody]

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

[throwaway894345]

That's not type safe.

[gfody]

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

[throwaway894345]

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.