Re: cataloguing NOT NULL constraints

Peter Eisentraut <peter_e@gmx.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.
        regards, tom lane