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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Geery <andrew(dot)geery(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Date: 2011-06-27 02:31:47
Message-ID: BANLkTimWEFL7WmxtATsU6xVaQpXpuy4rkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-06-27 02:33:06 Re: pg_upgrade defaulting to port 25432
Previous Message Bruce Momjian 2011-06-27 02:17:04 Re: pg_upgrade defaulting to port 25432