Re: Moving to postgresql and some ignorant questions

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Moving to postgresql and some ignorant questions
Date: 2007-08-14 17:56:51
Message-ID: 20070814135651.1fd56abe.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com>:

> > If you issue a BEGIN then nothing gets committed until you issue a COMMIT. If
> > anything happens in the meantime then everything you've done since the BEGIN
> > disappears.
>
> There are some cases where I would like to bunch queries into a
> transaction purely for speed purposes, but they're not interdependent
> for integrity. E.g.,
>
> BEGIN TRANSACTION;
> UPDATE1;
> UPDATE2;
> UPDATE3;
> COMMIT;
>
> If UPDATE2 fails because it, say, violates a foreign key constraint,
> then so be it. I want UPDATE3 to go ahead. Is this not possible, or is
> there an option I can use to do these kind of independent-query
> transactions?

That's not possible, by design.

However, your application could keep track of which queries have run, and
if one fails, start the transaction over without the failing query.

But the rule is, if any query within the transaction errors, then all queries
within the transaction are rolled back.

--
Bill Moran
http://www.potentialtech.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michal Paluchowski 2007-08-14 18:04:30 Creating a row during a select
Previous Message Phoenix Kiula 2007-08-14 17:46:34 Re: Moving to postgresql and some ignorant questions