Re: Information about columns

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

Responses

Browse pgsql-general by date

  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