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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, 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-24 23:01:49
Message-ID: BANLkTikd5DpCPYfE5ey__ZXQ6EGZ_FNgyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2011 at 6:39 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> So remind me ... did we discuss PRIMARY KEY constraints?  Are they
> supposed to show up as inherited not null rows in the child?  Obviously,
> they do not show up as PKs in the child, but they *are* not null so my
> guess is that they need to be inherited as not null as well.  (Right
> now, unpatched head of course emits the column as attnotnull).
>
> In this case, the inherited name (assuming that the child declaration
> does not explicitely state a constraint name) should be the same as the
> PK, correct?

I would tend to think of the not-null-ness that is required by the
primary constraint as a separate constraint, not an intrinsic part of
the primary key. IOW, if you drop the primary key constraint, IMV,
that should never cause the column to begin allowing nulls.

--
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 David Christensen 2011-06-24 23:11:56 Re: Deriving release notes from git commit messages
Previous Message Alvaro Herrera 2011-06-24 22:39:08 Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch