On 2011-12-30, Jan Bakuwel <jan.baku...@greenpeace.org> wrote: > This is a cryptographically signed message in MIME format. >
> What annoys me is that I don't think that a constraint violation made by > a user should result in an aborted transaction. There is probably a very > good reason to do that however the logic escapes me... the reason for it is it allows several updates (or other DML) to be run without checking for success and then success only checked at the commit stage. this makes it easier to the DBA to enforce databse consistancy against wayward applications and not suffer from partial inserts. > Of course I can start testing existing values in the database before > accepting them in the user interface but that's putting the horse behind > the cart. I much rather use the constraints at the database level to > tell me a particular update can't be done and do that without loosing > everything else I happened to have done in that transaction until that > point. > > Any suggestions? checkpoints can probably do what you want, but long-lived transactions are a bad idea in general, especially if you expect to have several physical users accessing your database simultaneously. -- ⚂⚃ 100% natural -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
