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 →
-
Catalog NOT NULL constraints
- e056c557aef4 16.0 landed