In article <24680.1245784...@sss.pgh.pa.us>, Tom Lane <t...@sss.pgh.pa.us> writes:
> Joshua Tolley <eggyk...@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. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
