SQL NULL representation:

I think the Right Thing is to use the Nothing subtype of a Maybe type, for which I have a pre-SRFI at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/MaybeEither.md>.  I have some code as well that is not yet online.

In the pre-SRFI, Nothing is a singleton of a unique record type.  The reason it's nice to use it in a SQL context is that we can represent a value from a non-nullable SQL integer column as a Scheme integer, but one from a nullable SQL column as a Maybe, specifically either the integer wrapped in Just or a Nothing.  This provides the advantage that (just 3) is not 3 and cannot be used as an exact integer until you have unwrapped it, which (depending on how you do it) either throws an exception on Nothing or else forces you to handle it with a default thunk.  I think this is a Very Good Thing. 

Trivalent logic:

I have incorporated Chicken's ternary-logic operators into the Maybe pre-SRFI, where "true" means "anything but #f or Nothing".  I don't think that we should try to guarantee that (let ((n (nothing))) (eq? n n) => #f, however; we would have to either modify eq? (and goodbye performance, which is the only reason to use eq? instead of eqv? anyhow) or guarantee that a new Nothing is constantly being generated (which would fail anyhow if Nothing was a procedure argument or result).

Instead, I have added `tri=?`, which returns #t iff its arguments are all true or all false.  Note that Nothing is like a more general version of NaN, and none of eq?, eqv?, or equal? makes any guarantees about NaN, although = does.

Arrays:

I have never used SQL arrays and don't know what to say about them.  They look to me like a way to cheat on first normal form; IMO the effort would have been better spent on pre-optimizing joins.  As for multi-dimensional arrays, we have two candidates, SRFI 122 and SRFI 164, and no good indication which, if either, will be voted into R7RS-large in the Orange ballot (upcoming).  So let's defer consideration of them.

JSON null:

I agree that JSON's null should be 'null rather than Nothing, so that parsed JSON can be displayed and passed around as an S-expression.

Postgres trailing spaces:

If they are added on update, they should be stripped on query, IMO.