primary key error message
in [PgSql]
|
From: Peter Eisentraut on 21 Jan 2010 17:06 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. -- 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: Robert Haas on 21 Jan 2010 17:06 On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: >> Why bother? > > Because unique constraints and primary keys are different things and it > would be slightly less confusing that way. I don't really see why it would be any less confusing. You could argue that someone might not know that the primary key acts like a unique constraint, but if they don't, then they might be confused about what it means to violate it. Generally if the user is looking at something like \d they will see the primary key as well as any unique indices. And the name of the primary key will match the name from this error message. So I'm also not sure how someone could get pointed in the wrong direction in the first place. >> 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? Of course, I have no control over what anyone discusses. This is a community and no one has a boss. But let me ask this. For which release were you hoping to make this change? If 9.0, then it seems to me that you've missed the deadline, which - according to my understanding of the agreed-upon schedule - was six days ago. Or perhaps you feel that that deadline should only apply to non-committers? If so, we should be clear about that, because I have a few things which I would have liked to submit but was unable to get done before the start of the CommmitFest. I would be more than happy to finish them up and propose them now, but my understanding is that I'm not supposed to do that. On the other hand, if you were hoping to make this change for 9.1, then obviously there is no issue of a deadline. However, there is still the issue of the CommitFest mandate, of which you are a proponent, which, in your exact words, says that one should not "work on new patches" during CommitFest and beta. http://archives.postgresql.org/pgsql-hackers/2009-06/msg01514.php I have previously expressed the view you might have been overreaching a bit in that email, because I don't think it's realistic to say that there is useful work for everyone to do during the entire time that we are in beta, and if there is nothing someone can do to get the release out sooner, then I think it's fine for them to work on their own patches. But that certainly isn't the case right now. ....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: Simon Riggs on 22 Jan 2010 09:22 On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote: > 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. In general, I agree that some error messages could be better. OTOH this kind of gradual and minor creep between releases is very annoying for our users, since you cannot rely on things remaining the same between releases. That costs people lots of money and isn't worth the marginal benefit, or alternatively prevents upgrades because of the need for application and admin tool recoding and retesting. "Stable software" isn't just software that doesn't break, it requires IIABDFI as well. -- Simon Riggs www.2ndQuadrant.com -- 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: Robert Haas on 22 Jan 2010 09:36 On Fri, Jan 22, 2010 at 9:22 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote: >> 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. > > In general, I agree that some error messages could be better. > > OTOH this kind of gradual and minor creep between releases is very > annoying for our users, since you cannot rely on things remaining the > same between releases. That costs people lots of money and isn't worth > the marginal benefit, or alternatively prevents upgrades because of the > need for application and admin tool recoding and retesting. "Stable > software" isn't just software that doesn't break, it requires IIABDFI as > well. Well put. ....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: Peter Eisentraut on 22 Jan 2010 09:50 On fre, 2010-01-22 at 14:22 +0000, Simon Riggs wrote: > "Stable software" isn't just software that doesn't break, it requires > IIABDFI as well. Yeah, I don't buy that. That would mean that you can never do maintenance, refactoring, or polishing. You basically just wait for the system to die a death somewhere between unmaintainability and ugliness. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] primary key error message Next: [HACKERS] warn in plperl logs as... NOTICE?? |