To: Joshua Tolley <eggyknap@gmail.com>
cc: Harald Fuchs <hari.fuchs@gmail.com>, pgsql-sql@postgresql.org
Subject: Re: Composite primary keys 
In-reply-to: <20090623184412.GG27474@eddie> 
References: <pu1vpb2d9f.fsf@srv.protecting.net> <20090623184412.GG27474@eddie>
Comments: In-reply-to Joshua Tolley <eggyknap@gmail.com>
	message dated "Tue, 23 Jun 2009 12:44:12 -0600"
Date: Tue, 23 Jun 2009 15:15:17 -0400
Message-ID: <24680.1245784517@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joshua Tolley <eggyknap@gmail.com> writes:
> Primary keys are NOT NULL and UNIQUE. You can't have null values in a primary
> key.

On reflection I think the OP's beef is that we complain about this:

regression=# create table t (f1 int null not null);
ERROR:  conflicting NULL/NOT NULL declarations for column "f1" of table "t"

but not this:

regression=# create table t (f1 int null primary key);    
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "t_pkey" for table "t"
CREATE TABLE

even though the implied NOT NULL is really a conflict.  I think we could
fix that case if we cared to.  However, since the NULL clause is
forgotten about after parsing, there isn't anything we could do to raise
a complaint about doing it in two steps:

regression=# create table t (f1 int null);            
CREATE TABLE
regression=# alter table t add primary key(f1);
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "t_pkey" for table "t"
ALTER TABLE

(barring remembering the NULL clause in the catalogs, which seems
entirely silly).  So I'm not sure how interesting it is to complain
about the single-command case.

			regards, tom lane