Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
