Tom Lane wrote: > Jan Wieck <[EMAIL PROTECTED]> writes: > > If at all, SET commands should behave like everything else. > > If done inside a transaction, they have to rollback. > > I have thought of a scenario that may be sufficient to justify fixing > SETs to roll back on transaction abort. Consider > > BEGIN; > > CREATE SCHEMA foo; > > SET search_path = 'foo, public'; > > ROLLBACK; > > As the code stands, this will leave you with an invalid search path. > (What's worse, if you now execute CREATE TABLE, it will happily create > tables belonging to the vanished namespace foo. Everything will seem > to work fine ... until you try to find those tables again in a new > session ...) > > It seems clear to me that SET *should* roll back on abort. Just a > matter of how important is it to fix.
That was my point, that having SET work pre-abort and ignored post-abort is broken itself, whether we implement timeout or not. Before we had tuple-reading SET variables, it probably didn't matter, but now with schemas, I can see it is more of an issue. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
