On Fri, Feb 29, 2008 at 4:45 PM, Graham Fawcett <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
