Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Bernd Helmle <mailings@oopsware.de>, Dean Rasheed <dean.a.rasheed@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Andrew Geery <andrew.geery@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-16T17:25:05Z
Lists: pgsql-hackers

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

Alvaro Herrera <alvherre@commandprompt.com> writes:
> So, question: do we need pg_constraint rows to exist for all NOT NULL
> constraints, including those in system catalogs, and including those in
> bootstrap catalogs?  If we're going to require that, we're going to need
> to add a few initial data lines to the pg_constraint catalog definition,
> plus some code to handle the other bootstrap cases (non bootstrap
> relations).

Installing such rows during bootstrap would be problematic, because what
do you do for catalogs that are created before pg_constraint?

Possible solution is to leave bootstrap's behavior alone, and have a
step during initdb's post-bootstrap stuff that creates a matching
pg_constraint row for every pg_attribute entry that's marked attnotnull.

> We could also declare that we don't need pg_constraint rows for NOT NULL
> constraints in system catalogs; but if we're going to do that, I guess
> we'd better disallow tables from inheriting system catalogs.

I have a feeling that omitting these entries for system catalogs would
bite us in other ways down the road, even if inheritance were the only
soft spot right now.

			regards, tom lane