On Mon, Apr 08, 2002 at 12:28:18PM -0400, Peter Eisentraut wrote:
> 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;
If I compare Peter's and Bruce's examples the Peter is still winner :-)
Sorry, but a code with "set-it-after-abort" seems ugly.
Karel
--
Karel Zak <[EMAIL PROTECTED]>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
