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