Re: PSQL undesired transaction behavior when connection is lost. - Mailing list pgsql-general

From Steven Klassen
Subject Re: PSQL undesired transaction behavior when connection is lost.
Date
Msg-id 20041007193334.GA12551@commandprompt.com
Whole thread Raw
In response to PSQL undesired transaction behavior when connection is lost.  (Mike Benoit <ipso@snappymail.ca>)
Responses Re: PSQL undesired transaction behavior when connection is lost.  (Steven Klassen <sklassen@commandprompt.com>)
Re: PSQL undesired transaction behavior when connection is lost.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
* Mike Benoit <ipso@snappymail.ca> [2004-10-07 11:47:50 -0700]:

> I assume I'm not the first person to run in to this, however
> searching google didn't seem to come up with anything useful.

AFAICT, the first query is just constructed poorly, while the second
seems to recurse on itself. The order in the sub-selects doesn't seen
necessary either.

> its=> begin; delete from pay_stub_entry where pay_stub_id in (select
> id from pay_stub where created_date >= 1096527603 order by
> created_date desc);

DELETE FROM pay_stub_entry
JOIN pay_stub ON (pay_stub_entry.pay_stub_id = pay_stub.id)
WHERE pay_stub.created_data >=1096527603;

> delete from pay_stub where id in (select id from pay_stub where
> created_date >= 1096527603 order by created_date desc); commit;

DELETE FROM pay_stub WHERE created_data >=1096527603;

--
Steven Klassen - Lead Programmer
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Replication & Support Services, (503) 667-4564

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: European dates with Win32 version
Next
From: David Fetter
Date:
Subject: DDL triggers [was Re: database constraints]