Not only would algebraic sum types be awesome, but if user-defineable they could eliminate so much of the ambiguity in how nulls are practically used in SQL. Pe

Not only would algebraic sum types be awesome, but if user-defineable they could eliminate so much of the ambiguity in how nulls are practically used in SQL. People often say that null just means unknown but that is a bug-causing simplification. In reality, null could mean unknown, but it could also mean not yet known, uninitialized, missing, impossible, uncomputable, join conditions not met, or hundreds of other things. And sum types would be extremely useful even outside of null handling...there are thousands of reasons why more and more modern languages are designed with sum types. Not only would sum types be extremely helpful but it would also be awesome to have a standard for product types. As it stands, some implementations have them but they are clunky, and others you have to resort to just using multiple columns, which is pretty bad for composability, bug-ridden, and leads to behavior that is almost like Hungarian notation in order to maintain unique column naming. For example: create table foo( start zoneddatetime, end zoneddatetime ... ); versus create table foo( start_time timestamp, start_tz timezone, end_time timestamp, end_tz timezone ... ); (timestamptz is not an acceptable substitute...it doesn't store timezone)