Re: [GENERAL] PSQL undesired transaction behavior when connection is lost.

2004-10-07 Thread Steven Klassen
* Tom Lane <[EMAIL PROTECTED]> [2004-10-07 16:33:26 -0400]: > Steven Klassen <[EMAIL PROTECTED]> writes: > > * Mike Benoit <[EMAIL PROTECTED]> [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 u

Re: [GENERAL] PSQL undesired transaction behavior when connection is lost.

2004-10-07 Thread Tom Lane
Steven Klassen <[EMAIL PROTECTED]> writes: > * Mike Benoit <[EMAIL PROTECTED]> [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 t

Re: [GENERAL] PSQL undesired transaction behavior when connection is lost.

2004-10-07 Thread Steven Klassen
* Steven Klassen <[EMAIL PROTECTED]> [2004-10-07 12:33:34 -0700]: > DELETE FROM pay_stub_entry > JOIN pay_stub ON (pay_stub_entry.pay_stub_id = pay_stub.id) > WHERE pay_stub.created_date >=1096527603; After RTFM'ing it appears you can't do actual joins with delete so we'll just have to daisy-chai

Re: [GENERAL] PSQL undesired transaction behavior when connection is lost.

2004-10-07 Thread Steven Klassen
* Mike Benoit <[EMAIL PROTECTED]> [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

[GENERAL] PSQL undesired transaction behavior when connection is lost.

2004-10-07 Thread Mike Benoit
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. 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 where