Re: [GENERAL] Re: [HACKERS] TRANSACTIONS - Mailing list pgsql-hackers

From Karl DeBisschop
Subject Re: [GENERAL] Re: [HACKERS] TRANSACTIONS
Date
Msg-id 200002241916.OAA07901@skillet.infoplease.com
Whole thread Raw
In response to Re: [GENERAL] Re: [HACKERS] TRANSACTIONS  ("Keith G. Murphy" <keithmur@mindspring.com>)
Responses Re: [GENERAL] Re: [HACKERS] TRANSACTIONS  (Lincoln Yeoh <lylyeoh@mecomb.com>)
List pgsql-hackers
To summarize, I stated that the following does not work with
postgresql:

> $dbh->{AutoCommit} = 0;
> $dbh->do("CREATE TABLE tmp (a int unique,b int)");
> while (<>){
>     if (/([0-9]+) ([0-9]+)/) {
>         $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");
>         if ($rtv) {$dbh->do("UPDATE tmp SET b=$2 where a=$1")};
>     }
> }
> $dbh->commit;
> $dbh->disconnect;

I further said that regardless of what the SQL standard gurus decide,
I felt that postgresql currently gives desirable behavior - once a
transaction is started, it's either all or nothing.  But then I
qualified that by saying I'd like somehow to be able to "sanitize" the
transaction so that the common idiom above could be made to work.

From my examination, the difference between our two examples is

Original:
KD>         $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");

Modified:
KM>         eval{$rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)")};

From the point of view if the DBMS, i believe these are identical - in
both cases the query is issued to the DMBS and the overall transaction
becomes "contaminated".  And as I said before, this is exactly what
I'd like to have happen in the default case.

It's not that eval's error trapping is blown out - it's that the
transaction defined by the AutoCommit cannot complete because a part
of it cannot complete -- that's what atomicity means.

At least that's the way it looks to me.  But as I started out saying,
I don't feel qualified to interpret the standard - I might be wrong,
plain and simple.

--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)

Information Please - your source for FREE online reference
http://www.infoplease.com  - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper

Netsaint Plugins Development
http://netsaintplug.sourceforge.net

pgsql-hackers by date:

Previous
From: Kyle
Date:
Subject: postgresql performance, smp vs non-smp
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] problems with TEMP table (6.5.3)