3 ms·
I suspect part of the problem is that true sum types are poorly represented in many of the languages that use these databases. In a sense because of the layer t
by zaphar 5y ago
I suspect part of the problem is that true sum types are poorly represented in many of the languages that use these databases. In a sense because of the layer these sit in the stacks they have to appeal to a lowest common denominator. If they supported tables where the rows were true sum types and polymorphic as a result many languages would find it quite difficult to interact with that database.
- throwaway894345 5y agoI don't understand why that would be a problem--programming languages interact with databases at runtime via SQL. I regularly use Go which lacks sum types, but there's nothing technically difficult about generating SQL that leverages sum types--except that SQL doesn't support sum types :).
- zaphar 5y agoIn Go returning a list of items that are one of a set of different types would be poorly handled. It's possible but very awkward. You would probably drop down to just a slice of interface{} and then have to use reflection to figure out what each item was. Dynamic languages like Python or Ruby would probably be fine but there are more languages than those out there to worry about.
- throwaway894345 5y agoThere are ways of modeling sum types in Go (a struct with a few fields and a tag, an interface that's only implemented by the relevant types, etc), but that's unrelated to the database/client interface.