| 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
| 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 |