Heh pardon me but... I was under the impression that for a transaction either all commands succeed or all commands fail, atleast according to everything I've ever read. So followign that all SETs done within the scope of a BEGIN/COMMIT pair should only take effect if the whole set finishes, if not the system shoudl roll back to the way it was before the BEGIN.
I might be missing something though, I just got onto the list and there might be other parts of the thread I missed.... Karel Zak wrote: >On Mon, Apr 08, 2002 at 01:03:41PM -0400, Tom Lane wrote: > >>The search_path case is the main reason why I'm intent on changing >>the behavior of SET; without that, I'd just leave well enough alone. >> > > Is there more variables like "search_path"? If not, I unsure if one > item is good consideration for change others things. > >>Possibly some will suggest that search_path shouldn't be a SET variable >>because it needs to be able to be rolled back on error. But what else >>should it be? It's definitely per-session status, not persistent >> > > It's good point. Why not make it more transparent? You want > encapsulate it to standard and current SET statement, but if it's > something different why not use for it different statement? > > SET SESSION search_path TO 'something'; > > (...or something other) > > Karel > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
