From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steven Klassen <sklassen(at)commandprompt(dot)com> |
Cc: | Mike Benoit <ipso(at)snappymail(dot)ca>, pgsql-general(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: PSQL undesired transaction behavior when connection is lost. |
Date: | 2004-10-07 20:33:26 |
Message-ID: | 23483.1097181206@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Steven Klassen <sklassen(at)commandprompt(dot)com> writes:
> * Mike Benoit <ipso(at)snappymail(dot)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.
Agreed, but I think that's irrelevant to his point: psql probably
should abandon whatever is left in its input buffer after getting an
error from the backend, and almost certainly should do so after loss
of connection. In the noninteractive case I believe it will quit
executing the script file, which is good, but in the interactive case
it seems like a mistake not to flush the query buffer.
Peter, do you know if this behavior was intentional, or just an
implementation artifact?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Klassen | 2004-10-07 20:39:31 | Re: PSQL undesired transaction behavior when connection is lost. |
Previous Message | Martijn van Oosterhout | 2004-10-07 20:22:24 | Question about timezones |