| I’ve always wondered why SQL doesn’t support variant types, and in this case especially. If you’re going to store a sequence of values whose type can change over time, a variant is the obvious encoding choice. As new schemas are introduced, you add constructors to the variant. On top of that, you can apply some basic structural reasoning to say eg a field can be indexed (possibly by different paths in each case) iff it exists in each constructor, or optionally with the awkward SQL nulls in case a field is not in each constructor (as they describe in the paper). But then you could also use general variant deconstruction to decide on a case-by-case basis how to handle each version or subset of versions of a schema, and having that capability to represent variants in user data, independent of “evolving schemas” could have significant general use as well. If you feel like having tuples and variants is too complicated, use dependent sigma types, so they’re all tuples, and then your schema language is much more expressive still. It’s weird how much database systems have stagnated on this front. |
Independently of schema evolution, a sum type can be implemented by using different nullable columns, and adding a multi-column CHECK constraint that (one and) only one of those columns must be set. One might want more syntactic sugar in SQL for that, but it would also complicate the language and data model, without really adding any new functionality.