Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Date
Msg-id 4815.1308245105@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "A.M."
Date:
Subject: Re: POSIX shared memory patch status
Next
From: Dan Ports
Date:
Subject: Re: patch: update README-SSI