From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: primary key error message |
Date: | 2010-01-21 22:06:25 |
Message-ID: | 1264111585.509.16.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote:
> regression=# alter table foo add primary key (f1);
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
> ERROR: could not create unique index "foo_pkey"
> DETAIL: Key (f1)=(1) is duplicated.
He he, that one doesn't even refer to a "constraint". Might also need
fixing. ;-)
> It is not incorrect to refer to a primary key as a unique constraint.
Some things need a primary key that is not only a unique constraint. So
having some clarity about that can be helpful.
> Will you next be wanting the error messages about null values to
> distinguish whether the NOT NULL constraint came from a primary key?
Hadn't thought of that, but it could actually become relevant when we
get named not null constraints.
But anyway, if there is no interest in this, then forget about it.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-21 22:06:28 | Re: primary key error message |
Previous Message | Tom Lane | 2010-01-21 22:06:08 | Re: PITR backup history files with identical 2nd part file names |