From: | Dario Teixeira <darioteixeira(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | John DeSoi <desoi(at)pgedit(dot)com>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Information about columns |
Date: | 2009-06-23 14:29:04 |
Message-ID: | 977541.74858.qm@web111503.mail.gq1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
> Why do you think that's a useful activity for client-side
> code to engage in?
Strongly typed languages like Ocaml and Haskell deal with the possibility
of missing values by having "option types". Though at first glance SQL's
NULL seems like a similar concept, in fact NULL is more like a constraint
on a table column instead of defining a different type. This impedance
mismatch causes some trouble when writing bindings that aim to preserve
type-safety.
I doubt there is a clean way around this (barring Postgresql implementing
option types). Therefore, I'm working on a workaround that involves the
Postgresql side annotating the nullability of type definitions by issuing
comments on the type (using COMMENT ON). Yes, it is a hack, but will solve
my problem as long as I can determine the return type (and thus fetch its
comment) associated with a query.
I know other people faced this problem before when writing Ocaml or Haskell
bindings, and that is why I know there is no straightforward solution. Still,
I welcome any thinking-outside-the-box suggestions...
Cheers,
Dario Teixeira
From | Date | Subject | |
---|---|---|---|
Next Message | Grzegorz Jaśkiewicz | 2009-06-23 14:29:50 | Re: Please suggest me on my table design (indexes!) |
Previous Message | Merlin Moncure | 2009-06-23 14:24:28 | Re: Replication |