| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: primary key error message |
| Date: | 2010-01-21 21:29:12 |
| Message-ID: | 14168.1264109352@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
>> This patch fails to cover all cases (index build being the obvious
>> omission, but I think there might be other paths as well where the
>> information is not so readily available).
> This is the user-visible error message, and that's the only place it's
> generated.
Hardly ...
regression=# create table foo (f1 int);
CREATE TABLE
regression=# insert into foo values(1),(1);
INSERT 0 2
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.
>> And I agree with Robert that the usefulness is at best highly debatable.
> The usefulness is that they are different kinds of objects that are
> defined and listed in different ways and it would be slightly helpful if
> the error message pointed in the righter direction.
It is not incorrect to refer to a primary key as a unique constraint.
Will you next be wanting the error messages about null values to
distinguish whether the NOT NULL constraint came from a primary key?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafael Martinez | 2010-01-21 21:49:56 | Re: PITR backup history files with identical 2nd part file names |
| Previous Message | Peter Eisentraut | 2010-01-21 21:24:16 | Re: primary key error message |