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

Alvaro Herrera <alvherre@commandprompt.com>

From: Alvaro Herrera <alvherre@commandprompt.com>
To: Bernd Helmle <mailings@oopsware.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-16T19:33:58Z
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

Excerpts from Bernd Helmle's message of jue jun 16 14:30:48 -0400 2011:
> 
> --On 16. Juni 2011 13:25:05 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > 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.
> 
> +1 for this idea. I never came to an end about this because i didn't have any 
> clue how to do it efficiently.

Okay, I have done it this way -- adding one more fixup function to
initdb is very easy.  I only wish that the ending \n in the query to
initdb would be optional -- it took me a while to realize that if you
omit it, the query doesn't get run at all.  Oh well.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support