Re: Information about columns

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

In response to

Browse pgsql-general by date

  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