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: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.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-29T17:07:25Z
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 Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of lun jun 27 10:35:59 -0400 2011:
>> On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
>> > I would summarise the consistency requirements as:
>> >
>> > 1). ADD CONSTRAINT should leave both parent and child tables in the
>> > same state as they would have been if the constraint had been defined
>> > at table creation time.
>> >
>> > 2). DROP CONSTRAINT should leave both parent and child tables in the
>> > same state as if the constraint had never existed (completely
>> > reversing the effects of ADD CONSTRAINT).
>> >
>> > I don't have a strong opinion as to whether or not the NOT NULL part
>> > of a PK should be inherited, provided that it is consistent with the
>> > above.
>> >
>> > I guess that if I were forced to choose, I would say that the NOT NULL
>> > part of a PK should not be inherited, since I do think of it as part
>> > of the PK, and PKs are not inherited.
>>
>> OK, I see your point, and I agree with you.
>
> Interesting.  This whole thing requires quite a bit of rejiggering in
> the initial transformation phase, I think, but yeah, I see the points
> here and I will see to them.  Does this mean that "NOT NULL PRIMARY KEY"
> now behaves differently?  I think it does , because if you drop the PK
> then the field needs to continue being not null.

Yeah, I think an implicit not-null because you made it a primary key
is now different from one that you write out.

> And here I was thinking that this was just a quick job to enable NOT
> VALID constraints ...

Bwahaha.

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