From: Jan Bakuwel <jan.bakuwel@greenpeace.org>
To: pgsql-sql@postgresql.org
Subject: Re: Current transaction is aborted, commands ignored until end of transaction block
Date: Sat, 31 Dec 2011 11:51:41 +1300
Message-ID: <4EFE407D.6090404@greenpeace.org> (raw)
In-Reply-To: <201112301044.33861.leif@solumslekt.org>
References: <4EFD3D32.9060902@greenpeace.org>
<13131805-BCBB-42DF-953B-27EE36AAF213@yahoo.com>
<4EFD79BA.50508@greenpeace.org>
<201112301044.33861.leif@solumslekt.org>
Hi Leif,
On 30/12/11 22:44, Leif Biberg Kristensen wrote:
> Fredag 30. desember 2011 09.43.38 skrev Jan Bakuwel :
>
>> Would be nice to have an option in PostgreSQL something along the lines
>> of: 'abort-transaction-on-constraint-violation = false'....
> That option is called MySQL with MyISAM tables.
>
> Seriously, if the user encounters a constraint violation, that is IMO a
> symptom of bad design. Such conditions should be checked and caught _before_
> the transaction begins.
Really?
One of my detail tables here is a list of codes. The design currently is
so that you are not allowed to add two identical codes in that table for
a particular related master record, ie. if you try it raises a
constraint violation (duplicate key). Users try anyway (you know those
pesky users doing things they're not supposed to do).
Why would that a bad design?
I simply want to tell the user: sorry you can't do this because it
violates a constraint (duplicate key).
Sometimes they try to delete something that has other records referring
to it and the database design is so that it won't cascade delete (for
various reasons). In that case I want to tell them: sorry you can't do
this because there are related records.
In a well designed system, you'd have those constraints at the database
level not the application level and use exception handling to deal with
these, not write tests to find out the possible error conditions
beforehand. Of course it's possible to write code around all of this
(and I'm starting to realise that is what I might have to do) but I
consider that bad design.
I don't claim to know all other RDBMS but I think PostgreSQL might be
one of the few (or only one) that considers a constraint violation
something really really really serious... so serious that the
transaction will have to be aborted. Quite a few other RDBMS will give
you the error but will also allow you to continue on your merry way (and
not loose everything you've done up to that point).
Why-o-why have the PostgreSQL developers decided to do it this way...?
regards,
Jan
Attachments:
[application/pkcs7-signature] smime.p7s (5.6K, ../4EFE407D.6090404@greenpeace.org/2-smime.p7s)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: jan.bakuwel@greenpeace.org
Subject: Re: Current transaction is aborted, commands ignored until end of transaction block
In-Reply-To: <4EFE407D.6090404@greenpeace.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox