From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
Cc: | Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Composite primary keys |
Date: | 2009-06-23 19:15:17 |
Message-ID: | 24680.1245784517@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Joshua Tolley <eggyknap(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2009-06-23 20:30:37 | Client-side compression |
Previous Message | Joshua Tolley | 2009-06-23 18:44:12 | Re: Composite primary keys |