Re: [Chicken-users] New immediate values (was: DBI)

[felix winkelmann]

On Fri, Feb 29, 2008 at 4:45 PM, Graham Fawcett
<address@hidden> wrote:
>
>  Could it? I'm looking at Postgres, and wondering how to come up with a
>  consistent approach for handling user-defined datatypes. There's no
>  right solution, and the best compromise is to let the user register
>  in/out translation functions. An out-function could translate a value
>  in a custom type into anything, including a symbol (unless we
>  *specify* that this should be illegal).
>
>  Should it? If we are approaching a common dbi, we should decide now.
>  But it feels premature to rule out an entire datatype for lack of a
>  good "null" type.

Yes, I guess you're right here.

>
>  For representing sql-null, the special immediate-type solution is best
>  because it's unambiguous. If that were ruled out, simply using the
>  symbol 'null -- and forbidding database layers from returning symbols
>  as output-values other than 'null -- would be my second choice, but
>  it's an inferior solution, and I have a feeling I'd regret it later.
>  But please not '(), for the same reason not #f, 0, or an empty string.
>
>
>  >  cheers,
>  >  felix (who would like to keep the number of immediate types small)
>
>  I don't want to see a circus of immediate types either, but one more
>  isn't horrible. I thought (void) was perfect for this, but I respect
>  the concerns that have been raised. So, (void) needs a brother who has
>  no semantic baggage.
>

Wether an sql-null value is immediate or not is an implementation
detail which has no relevance to the discussion of a DBI API.


cheers,
felix