Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Bernd Helmle <mailings@oopsware.de>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Geery <andrew.geery@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bruce Momjian <bruce@momjian.us>
Date: 2011-06-27T02:31:47Z
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

On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> Really? I would expect the reverse, namely that the not-nullness is
> part of the PK constraint and dropping the PK *would* then start
> allowing NULLs.

Hmm, OK.  I had assumed we were only trying to fix the problem that
parent and child inheritance tables could get out of step, but maybe
you're right.

If we go with that approach, then consider:

CREATE TABLE foo (a int);
CREATE TABLE bar () INHERITS (foo);

Now if someone adds a primary key foo (a), what happens currently is
that foo.a becomes NOT NULL, but bar.a still allows NULLs.  Should
that remain true (on the theory that a primary key constraint is not
inherited) or become false (on the theory that parent and child tables
should match)?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company