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