Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think our SET functionality is easy to understand and use. I don't
> see pushing it into the client as greatly improving things, and could
> make things worse. If we can't get it right in the backend, how many
> clients are going to do it wrong?
This argument overlooks the fact that most of the client libraries
already have notions of autocommit on/off semantics that they need to
adhere to. libpq is too simple to have heard of the concept, but I
believe that JDBC, ODBC, and DBI/DBD all need to deal with it anyway.
I doubt that managing a server-side facility makes their lives any
easier ... especially not if its semantics don't quite match what
they need to do, which seems very possible.
But it'd be interesting to hear what the JDBC and ODBC maintainers
think about it. Perhaps autocommit as a GUC variable is just what
they want.
Please recall that GUC-autocommit in its current form was my idea,
and I rushed it in there because I wanted us to be able to run the
NIST compliance tests easily. In hindsight I am thinking it was a
bad move.
regards, tom lane
