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.
Uh, yes, we could allow the second SET to succeed even in an aborted
transaction, but Tom says his schema stuff will not work in an aborted
state, so Tom/I figured the only other option was rollback of the first
SET.
> > 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;
Yes, but why bother with that when rollback of the first SET is cleaner
and more predictable?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026