Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Why exactly did you want the initial SET to not be part of the > > transaction? > > Primarily because existing client-side libraries issue lots of SETs > while starting a connection. > > We may just have to say "those guys are broken if you turn off > autocommit in postgresql.conf", but I am looking for a way around it. > If SET didn't start a transaction then they wouldn't be broken...
OK, I can work with this. If we assume the startup is the first statement issued, then we could tell them they have to SET autocommit to on first before doing anything else. However, if you believe there could have been other SET's before the startup stuff, my idea doesn't work because autocommit has to be at the start of a transaction. If you think there could have been other non-SET queries before the startup script, then all of our ideas don't work because the SET would already be in a transaction. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
