>> SQL NULL representation: [Just x | Nothing]
>
> This sounds extremely painful to work with, especially when you know that
> NULLs are never there, even if the column itself may be nullable (due to
> a WHERE condition, for example).
>
> There's also a problem with this definition, because you can't know what
> column a value is coming from.  Also, it might not even map to a column
> at all:  (SELECT 1, 'foo' UNION SELECT NULL, NULL); will have a result
> set which is typed as int, text.  There's no information on whether the
> types may be nullable.

Very good points.

>> So let's defer consideration of [arrays].
>
> Sure, most databases don't have them, so it's more of a driver-specific
> issue I think.

Might be worth gathering a list of all popular databases that have
arrays (or JSON-like structures) and finding out what commonalities can
be extracted.

>> Postgres trailing spaces:
>>
>> If they are added on update, they should be stripped on query, IMO.
>
> You can't distinguish from spaces added by the padding of the CHAR(n)
> type and spaces that were present in the original string.  Given that
> the extra spaces simply reflect how it's actually stored, I think it's
> best to simply return what the database returns.

Agree with this too. I'd leave any round-trip guarantees up to the
database engine, not to our Scheme stuff. Round-trip compatibility is
complicated and subject to change with DB configuration options and new
engine versions.