Re: [GENERAL] Re: [HACKERS] TRANSACTIONS

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