On Fri, Sep 13, 2019 at 04:38:05PM -0400, John Cowan wrote:
> 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.

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.

> 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.

> 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.

Note that this is not specific to Postgres.  All SQL databases have the
CHAR(n) type, AFAIK.

Cheers,
Peter