Re: Composite primary keys

In article <24680.1245784517@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> writes:

> 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.

Yes, that's exactly what I found strange.

> 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).

I thought nullability is the default anyway, so indeed no need to
remember it.  My gripe was really the first case, where you contradict
yourself in a single DDL statement.