Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 9876AB5DBC1
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri,  5 Aug 2011 22:23:51 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 38900-03
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Sat,  6 Aug 2011 01:23:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 29736B5D8C5
	for <pgsql-hackers@postgresql.org>;
	Fri,  5 Aug 2011 22:23:45 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p761Nfpv028685;
	Fri, 5 Aug 2011 21:23:41 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Alvaro Herrera <alvherre@commandprompt.com>,
	Dean Rasheed <dean.a.rasheed@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: cataloguing NOT NULL constraints 
In-reply-to: <1312588885.24208.40.camel@vanquo.pezone.net> 
References: <20110707213401.GA27098@alvh.no-ip.org>
	<CAEZATCVX792JjZHrv+CdO87GmJ1uo01AH+OQbcymspEyjyhyaQ@mail.gmail.com>
	<1311291819-sup-6206@alvh.no-ip.org>
	<CA+TgmoaJbuai2wiWjYUMsawZQL57wOhP7Kg9q=kkVO8qc97MQQ@mail.gmail.com>
	<1311367030-sup-9426@alvh.no-ip.org>
	<CA+TgmobQSR7QHfvH8fQ7dvUabQMBdFc1=Ef7ceJL9qeOm8Y1iw@mail.gmail.com>
	<CAEZATCW_GXNedWnkJ6Jv98-AxtiSNL44dq-jx566JBLiye-dkg@mail.gmail.com>
	<CA+TgmoaT7Np=k39aH=D=dpRYKJ=gwXmRMA029BBs0jBs--fD6w@mail.gmail.com>
	<1311985058-sup-952@alvh.no-ip.org>
	<CAEZATCU5mSytH6Buxp2YJ_ExwNcmbrYG8TKXc3Wg-EHLO78cWQ@mail.gmail.com>
	<1312342392-sup-7189@alvh.no-ip.org>
	<1312480674.24208.8.camel@vanquo.pezone.net>
	<1312488608-sup-8244@alvh.no-ip.org>
	<1312588885.24208.40.camel@vanquo.pezone.net>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Sat, 06 Aug 2011 03:01:25 +0300"
Date: Fri, 05 Aug 2011 21:23:41 -0400
Message-ID: <28684.1312593821@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.831 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	RP_MATCHES_RCVD=-0.931
X-Spam-Level: 
X-Archive-Number: 201108/285
X-Sequence-Number: 193040

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