Re: cataloguing NOT NULL constraints

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Alvaro Herrera" <alvherre@commandprompt.com>, "Pg Hackers" <pgsql-hackers@postgresql.org>
Date: 2012-08-16T16:08:15Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
 
> I think that a NOT NULL constraint attached to a column with a
> composite type is equivalent to a CHECK (col IS DISTINCT FROM
> NULL); at least they seem to behave identically.  Is that what you
> would expect?
 
I had not thought about that, but now that you point it out I think
that interpretation makes more sense than any other.  In a quick
test they behaved identically for me.
 
> This seems a bit complicated to handle with the way I'm doing
> things today; at parse analysis time, when my current code is
> creating the check constraint, we don't know anything about the
> type of the column IIRC.  Maybe I will have to delay creating the
> constraint until execution.
 
Why?  CHECK (col IS DISTINCT FROM NULL) works correctly for *any*
type, doesn't it?
 
-Kevin


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Catalog NOT NULL constraints