From: | Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Composite primary keys |
Date: | 2009-06-24 08:37:37 |
Message-ID: | puiqim10z2.fsf@srv.protecting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
In article <24680(dot)1245784517(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jasen Betts | 2009-06-24 12:13:59 | Re: Client-side compression |
Previous Message | Rob Sargent | 2009-06-23 20:30:37 | Client-side compression |