Thomas Lockhart wrote:
> > > I consider SET variables metadata that are not affected by transactions.
> > Why? Again, the fact that historically they've not acted that way isn't
> > sufficient reason for me.
>
> Hmm. Historically, SET controls behaviors *out of band* with the normal
> transaction mechanisms. There is strong precedent for this mechanism
> *because it is a useful concept*, not simply because it has always been
> done this way.
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. We ignore normal queries during an ABORT
because the transaction can't possibly change any data because it is
aborted, and the previous non-SET statements in the transactions are
rolled back. However, the SET commands are not.
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. To make this work, you would need this:
BEGIN WORK;SET query_timeout=20;query fails;SET query_timeout=0;COMMIT WORK;SET query_timeout=0;
which seems kind of strange. The last SET is needed because the query
may abort and the second SET ignored.
> *If* some aspects of SET take on transactional behavior, then this
> should be *in addition to* the current global scope for those commands.
My point is that SET already doesn't have session behavior because it is
ignored if the transaction has already aborted.
-- 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
