Обсуждение: getting details about integrity constraint violation
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>
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
| |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?
В Птн, 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>
> 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 >
-----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=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFCrIsevJuQZxSWSsgRAh+gAJ94AsB7rZzpxT7pogC1tgbPaQJzJQCg5YkC E9dXkQk4qP8r8zjCEucxpt0= =NDgJ -----END PGP SIGNATURE-----
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>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> 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?
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=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFCr4zivJuQZxSWSsgRAgGPAJ0awkoBmus6z1cLBRpsR5xmQPTfiACgpJxG
Ld90hEGDPrebBE3JGGL11L4=
=smQJ
-----END PGP SIGNATURE-----