Hiroshi Inoue wrote: > > I'd be willing to consider making the behavior variable-specific > > if anyone can identify particular variables that need to behave > > differently. But overall I think it's better that the behavior > > be consistent --- so you'll need a good argument to convince me > > that anything should behave differently ;-). > > > > There is a variant case that should also have been illustrated: > > what if there is no error, but the user does ROLLBACK instead of > > COMMIT? The particular case that is causing difficulty for me is > > > > begin; > > create schema foo; > > set search_path = foo; > > rollback; > > > > There is *no* alternative here but to roll back the search_path > > setting. > > begin; > xxxx; > ERROR: parser: parse error at or near "xxxx" > > There's *no* alternative here but to call *rollback*(commit). > However PostgreSQL doesn't call *rollback* automatically and > it's the user's responsibility to call *rollback* on errors. > IMHO what to do with errors is users' responsibility basically. > The behavior of the *search_path" variable is a *had better* > or *convenient* kind of thing not a *no alternative* kind > of thing.
I understand from an ODBC perspective that it is the apps responsibility, but we need some defined behavior for a psql script that is fed into the database. Assuming the SET commands continue to come after it is aborted but before the COMMIT/ROLLBACK, we need to define how to handle it. -- 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])
