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

From
Subject Re: [GENERAL] Re: [HACKERS] TRANSACTIONS
Date
Msg-id Pine.LNX.4.10.10002251447090.16512-100000@picasso.realtyideas.com
Whole thread Raw
In response to Re: [GENERAL] Re: [HACKERS] TRANSACTIONS  (Karl DeBisschop <kdebisschop@range.infoplease.com>)
Responses Re: [GENERAL] Re: [HACKERS] TRANSACTIONS  (Karl DeBisschop <kdebisschop@range.infoplease.com>)
List pgsql-general

On Fri, 25 Feb 2000, Karl DeBisschop wrote:

>
> >>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)");
> >>>         $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;
> >>
>
> The usefulness of the idion is that in a mutli-user environment, this
> is a basic way to update data that may or may not already have a key
> in the table.  You can't do a "SELECT COUNT" because in the time
> between when you SELECT and INSERT (assuming the key is not already
> there) someone may have done a separate insert.  The only other way I
> know to do this is to lock the entire table against INSERTs which has
> obvious performance effects.
sounds right, but ;-) why you use the transaction in the first place?


pgsql-general by date:

Previous
From: Karl DeBisschop
Date:
Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS
Next
From: "Keith G. Murphy"
Date:
Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS