Subject: Re: cataloguing NOT NULL constraints
From: Peter Eisentraut <peter_e@gmx.net>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Robert Haas
	<robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
In-Reply-To: 
 <CAEZATCV5VFObFEDrK0U-4_UBneycREwFq+RroCK3AeeEfph4_A@mail.gmail.com>
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>
	<CAEZATCWhTAsA7RG4BESqFXuLhmRUUEvpC0tr_qv0Eok81Xa3qQ@mail.gmail.com>
	<1312624993.24721.16.camel@vanquo.pezone.net>
	<CAEZATCV5VFObFEDrK0U-4_UBneycREwFq+RroCK3AeeEfph4_A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 07 Aug 2011 12:43:52 +0300
Message-ID: <1312710232.24721.19.camel@vanquo.pezone.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On lör, 2011-08-06 at 12:58 +0100, Dean Rasheed wrote:
> Right now \d gives:
> 
>       Table "public.foo"
>  Column |  Type   | Modifiers
> --------+---------+-----------
>  a      | integer | not null
>  b      | integer |
>  c      | integer |
> Check constraints:
>     "foo_b_check" CHECK (b IS NOT NULL)
>     "foo_c_check" CHECK (NOT c IS NULL)
> 
> With this approach, one change would be that you'd gain an extra "not
> null" in the Modifiers column for "b".
> 
> But how many CHECK constraints would show? I guess it would show 3,
> although it could be changed to just show 1. But it certainly couldn't
> continue to show 2, since nothing in the catalogs could distinguish
> the constraints on "a" from those on "b".

I'd say we would show all (what is currently known as) NOT NULL
constraints under "Check constraints:".