Horton

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

Alvaro Herrera <alvherre@commandprompt.com>

View thread
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Robert Haas <robertmhaas@gmail.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-29T22:42:19Z
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

Excerpts from Robert Haas's message of mié jun 29 18:16:20 -0400 2011:
> On Wed, Jun 29, 2011 at 4:59 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
> > Excerpts from Robert Haas's message of mié jun 29 13:07:25 -0400 2011:
> >> 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:
> >
> >> > 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.
> >
> > Actually, it wasn't that hard, but I'm not really sure I like the
> > resulting code:
> 
> What don't you like about it?

Scribbling on attnotnull like that seems ... kludgy (we have to walk the
attr list three times: first to copy, second to reset all the attnotnull
flags, third to set those of interest).  The fact that we need a copy to
scribble on, seems wrong as well (we weren't creating a copy before).
The existing mechanisms to copy tupledescs aren't very flexible, but
improving that seems overengineering to me.

> My concern is that I'm not sure it's correct...

Ah, well, I don't see any reason not to trust it currently.  I am afraid
it could easily break in the future though.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support