primary key error message
in [PgSql]
|
From: Robert Haas on 21 Jan 2010 15:47 On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > Here is a small patch that changes the error message > > duplicate key value violates unique constraint "%s" > > into > > duplicate key value violates primary key "%s" > > when the constraint is in fact a primary key. > > Comments? Why bother? And why bother now, when we're in the middle of the last CommitFest and trying to move toward a release? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 Jan 2010 15:51 Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: >> Here is a small patch that changes the error message >> >> � �duplicate key value violates unique constraint "%s" >> >> into >> >> � �duplicate key value violates primary key "%s" >> >> when the constraint is in fact a primary key. >> >> Comments? > Why bother? And why bother now, when we're in the middle of the last > CommitFest and trying to move toward a release? 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). And I agree with Robert that the usefulness is at best highly debatable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 21 Jan 2010 16:22 On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > >> Here is a small patch that changes the error message > >> > >> duplicate key value violates unique constraint "%s" > >> > >> into > >> > >> duplicate key value violates primary key "%s" > >> > >> when the constraint is in fact a primary key. > >> > >> Comments? > > > Why bother? And why bother now, when we're in the middle of the last > > CommitFest and trying to move toward a release? > > 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. > 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 21 Jan 2010 16:24 On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote: > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > > Here is a small patch that changes the error message > > > > duplicate key value violates unique constraint "%s" > > > > into > > > > duplicate key value violates primary key "%s" > > > > when the constraint is in fact a primary key. > > > > Comments? > > Why bother? Because unique constraints and primary keys are different things and it would be slightly less confusing that way. > And why bother now, when we're in the middle of the last > CommitFest and trying to move toward a release? Are you saying we can't discuss anything new during the commit fest? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 Jan 2010 16:29 Peter Eisentraut <peter_e(a)gmx.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] primary key error message Next: [HACKERS] warn in plperl logs as... NOTICE?? |