|
Home > Archive > PostgreSQL SQL > June 2005 > getting details about integrity constraint violation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
getting details about integrity constraint violation
|
|
| Markus Bertheau 2005-06-02, 11:24 am |
| Hi,
how would I find out details about for example what constraint was
violated by an insert statement? The SQL state tells me, that a unique
constraint was violated, but it doesn't say which one. I cannot sensibly
react to such errors if I don't know what exactly happened.
I'd like to avoid parsing the text error message because it can be
different depending on the LC_MESSAGES the server / libpq runs with.
Markus
--
Markus Bertheau <twanger@bluetwanger.de>
| |
| Tom Lane 2005-06-02, 11:24 am |
| Markus Bertheau <twanger@bluetwanger.de> writes:
> how would I find out details about for example what constraint was
> violated by an insert statement?
You can't, at the moment, except by parsing the text message.
The "error fields" facility in the FE/BE protocol could be extended
in that direction, and I think there's already been some discussion
about it; but no one has stepped up with a concrete proposal, much
less volunteered to do the work ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| KÖPFERL Robert 2005-06-03, 3:23 am |
|
|
|You can't, at the moment, except by parsing the text message.
|
|The "error fields" facility in the FE/BE protocol could be extended
|in that direction, and I think there's already been some discussion
|about it; but no one has stepped up with a concrete proposal, much
|less volunteered to do the work ...
|
| regards, tom lane
So there must be at least a bunnch of error codes (which could be printed in
addition)?
Or has noone defined such, yet?
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
| |
| Markus Bertheau ☠2005-06-03, 7:23 am |
| В Птн, 03/06/2005 в 10:00 +0200, KÖPFERL Robert пишет:
> |
> |You can't, at the moment, except by parsing the text message.
> |
> |The "error fields" facility in the FE/BE protocol could be extended
> |in that direction, and I think there's already been some discussion
> |about it; but no one has stepped up with a concrete proposal, much
> |less volunteered to do the work ...
> |
> | regards, tom lane
>
>
> So there must be at least a bunnch of error codes (which could be printed in
> addition)?
There are, but they only say something along the lines of "unique
constraint violated", they don't say which one.
Markus
--
Markus Bertheau â˜_ <twanger@bluetwanger.de>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
| |
|
|
> The "error fields" facility in the FE/BE protocol could be extended
> in that direction, and I think there's already been some discussion
> about it; but no one has stepped up with a concrete proposal, much
> less volunteered to do the work ...
Um, if changing the protocol is a bother, you could also add parseable
infos to the error messages...
instead of :
"ERROR: duplicate key violates unique constraint "testinteg_one_key""
it would say
"ERROR: duplicate key violates unique constraint "testinteg_one_key"
[code:"XXXX" error:"integrity" type:"unique" column:"something"
constraint:"testinteg_one_key"]"
Which could be hackfully added by a "parseable" locale (but with a more
restrained form...)
SET lc_messages TO parseable
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql
.org so that your
> message can get through to the mailing list cleanly
>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Greg Sabino Mullane 2005-06-14, 3:24 am |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Markus Bertheau asked:
> how would I find out details about for example what constraint was
> violated by an insert statement? The SQL state tells me, that a unique
> constraint was violated, but it doesn't say which one.
Simply name the table constraints yourself with a descriptive name, so you
always know exactly what is going on:
greg=# create table unitest(a int, b text);
CREATE TABLE
greg=# alter table unitest add constraint " unitest_column_a_is_
not_unique" unique(a);
NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index " unitest_column_a_is_
not_unique" for table "unitest"
greg=# insert into unitest (a) values (1);
INSERT 0 1
greg=# insert into unitest (a) values (1);
ERROR: duplicate key violates unique constraint " unitest_column_a_is_
not_unique"
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506121520
http://biglumber.com/x/web? pk=2529...14964
AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFCrIsevJuQZxSW
SsgRAh+gAJ94AsB7rZzp
xT7pogC1tgbPaQJzJQCg
5YkC
E9dXkQk4qP8r8zjCEucx
pt0=
=NDgJ
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Markus Bertheau 2005-06-14, 3:24 am |
| Dnia 14-06-2005, wto o godzinie 03:39 +0000, Greg Sabino Mullane
napisał(a):
> Simply name the table constraints yourself with a descriptive name, so you
> always know exactly what is going on:
And then I keep a list of all the constraint names and scan the error
message for it?
Markus
--
Markus Bertheau <twanger@bluetwanger.de>
| |
| Greg Sabino Mullane 2005-06-15, 3:24 am |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[color=darkred]
> And then I keep a list of all the constraint names and scan the error
> message for it?
Don't keep a list: just come up with a standard naming scheme, such as:
" tablename|colname|is
_not_unique"
which should be human and machine parseable (perl example):
if ($error =~ m#^(.+)\|(. +)\|is_not_unique$#o
) {
die qq{Whoops : looks like column "$2" of table "$1" needs to be unique\n};
}
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506142204
http://biglumber.com/x/web? pk=2529...14964
AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFCr4zivJuQZxSW
SsgRAgGPAJ0awkoBmus6
z1cLBRpsR5xmQPTfiACg
pJxG
Ld90hEGDPrebBE3JGGL1
1L4=
=smQJ
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
|
|
|
|
|