Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, I now think that saving the SET commands that are ignored in a
> > transaction and running them _after_ the transaction completes may be
> > the best thing.
>
> No, that's just plain ridiculous. If you want to change the semantics
No more ridiculous than what we have now.
> of SET, then make it work *correctly*, viz like an SQL statement: roll
> it back on transaction abort. Otherwise leave it alone.
I am not going to leave it alone based only on your say-so, Tom.
> > If we don't somehow get this to work, how do we do timeouts, which we
> > all know we should have?
>
> This is utterly unrelated to timeouts. With or without any changes in
> SET behavior, JDBC would need to issue a SET after completion of the
> transaction if they wanted to revert a query_timeout variable to the
> no-timeout state.
"Utterly unrelated?" No. If we can get SET to work properly in
transactions, jdbc can cleanly issue SET timeout=4, statement, SET
timeout=0. Without it, using SET for timeout is a problem. That's how
we got to this issue in the first place.
I am still looking for a constructive idea on how we can get this to
work, rather than calling my ideas "ridiculous".
-- 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
