From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dario Teixeira <darioteixeira(at)yahoo(dot)com> |
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:36:23 |
Message-ID: | 14305.1245767783@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dario Teixeira <darioteixeira(at)yahoo(dot)com> writes:
> 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.
Okay, but that has nothing to do with either functions or composite
types.
The reasonable way to handle this in Postgres (IMHO) would be to define
not-null domains over the types you care about, and then lobby us to
have RowDescription return domain OIDs instead of smashing domains to
their base types. I don't recall the exact reasoning for the domain
smashing behavior; perhaps it could be made adjustable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-06-23 14:43:59 | Re: after vacuum analyze, explain still wrong |
Previous Message | Ivan Sergio Borgonovo | 2009-06-23 14:35:39 | drawback of array vs join |