Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073