Bruce Momjian writes: > OK, probably good time for summarization. First, consider this: > > BEGIN WORK; > SET something; > query fails; > SET something else; > COMMIT WORK; > > Under current behavior, the first SET is honored, while the second is > ignored because the transaction is in ABORT state. I can see no logical > reason for this behavior.
But that is not a shortcoming of the SET command. The problem is that the system does not accept any commands after one command has failed in a transaction even though it could usefully do so. > The jdbc timeout issue is this: > > > BEGIN WORK; > SET query_timeout=20; > query fails; > SET query_timeout=0; > COMMIT WORK; > > In this case, with our current code, the first SET is done, but the > second is ignored. Given appropriate functionality, you could rewrite this thus: BEGIN WORK; SET FOR THIS TRANSACTION ONLY query_timeout=20; query; COMMIT WORK; -- Peter Eisentraut [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
