Date: Fri, 18 Mar 2005 05:19:28 -0800 (PST)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Kenneth Gonsalves <lawgon@thenilgiris.com>
Cc: Richard Huxton <dev@archonet.com>, weberp@paradise.net.nz,
	pgsql-sql@postgresql.org
Subject: Re: Query performance problem
In-Reply-To: <200503181049.47566.lawgon@thenilgiris.com>
Message-ID: <20050318051614.Q61964@megazone.bigpanda.com>
References: <200503172120.20676.weberp@paradise.net.nz>
	<200503171801.19412.lawgon@thenilgiris.com>
	<42398EB9.2050707@archonet.com>
	<200503181049.47566.lawgon@thenilgiris.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 18 Mar 2005, Kenneth Gonsalves wrote:

> On Thursday 17 Mar 2005 7:35 pm, Richard Huxton wrote:
>
> > Not necessarily. NOT NULL here helps to ensure you can add values
> > together without the risk of a null result. There are plenty of
> > "amount" columns that should be not-null (total spent, total
> > ordered etc).
>
> that makes sense - but is it necessary to have a not null constraint
> when there is a default value?

It's also an added check which prevents you from explicitly setting the
value to NULL in an insert or update, since
"insert into foo(col1) values (NULL);" shouldn't insert the default value
into col1.  This is relatively minor generally, but if you have queries
whose behavior is broken by NULLs (things using IN/NOT IN for example)
it's better to be safe.