pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: cataloguing NOT NULL constraints
Date: Fri, 05 Aug 2011 21:23:41 -0400
Message-ID: <28684.1312593821@sss.pgh.pa.us> (raw)
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>

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



view thread (196+ messages)  latest in thread

Message-ID: <28684.1312593821@sss.pgh.pa.us>
Permalink:  ../28684.1312593821@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/28684.1312593821@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, peter_e@gmx.net, alvherre@commandprompt.com, dean.a.rasheed@gmail.com, robertmhaas@gmail.com
  Subject: Re: cataloguing NOT NULL constraints
  In-Reply-To: <28684.1312593821@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox