On Wed, May 04, 2011 at 07:03:31PM +0200, Marek Więckowski wrote: > (and this is why I was looking into this in the first place). There is a > danger that client programs will continue issuing queries while believing > that > they are in a transaction... They do expect db errors and rolled back > transactions, but not that their begin-commit section would be executed only > partially.
I don't understand. If they are prepared for errors, then if they have any error they have to roll back to the beginning of the savepoint or the transaction if there's no savepoint. What is this "partial execution" of which you speak? Nothing is partially executed: if the transaction rolls back, everything is lost. > good (and the alternative sounds more complex: it would require exposing > extra > info to the programs using this library, and add handling of reconnect > situation in each of these programs etc.). [. . .] > 4. if we were in a trans before disconnect, then immediately after > reconnecting we would create a trans-in-error. You're going to have to expose trans-in-error to the client anyway. What's the difference between that and exposing the program to needing to fix its connection? A -- Andrew Sullivan a...@crankycanuck.ca -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
