Re: cataloguing NOT NULL constraints

Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
> >> Yeah, perhaps you're right. The main reason they were considered
> >> separately is that we wanted to have them to be optimized via
> >> pg_attribute.attnotnull, but my patch does away with the need for that
> >> because it is maintained separately anyway.
>
> > Hmm, OK, but in any case you could have kept attnotnull and treated it
> > as a kind of optimization that indicates whether you can derive
> > not-nullability from existing CHECK constraints (which you can easily do
> > in enough cases).
>
> Yes. I thought that was how we were going to do it, and I'm rather
> distressed to hear of attnotnull going away. Even if there were not a
> performance reason to keep it (and I'll bet there is), you can be sure
> that removing that column will break a lot of client-side code. See
> recent complaints about Robert removing relistemp, which has only been
> around for a release or two. attnotnull goes back to the beginning,
> more or less.

Err, obviously I didn't express myself very well. I am not removing the
column. What I tried to say is that we no longer need to optimize the
representation of NOT NULL as separate entities from CHECK constraints,
because attnotnull is maintained separately from the pg_constraint
entries. In other words, from that point of view, representing NOT NULL
as CHECK is not a problem from a performance POV, because it is already
taken care of by letting attnotnull continue to represent them as a
cache.

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