autocommit in 7.4

Hello Bruce,

Tuesday, July 22, 2003, 11:26:32 PM, you wrote:

BM> I see autocommit as implemented only in psql, not in libpq. Is that
BM> what we want to do for 7.4?

Autocommit with libpq could be a good idea for web applications, especially
when not so expirienced users connect from a scripting language. They often
have really no idea what a transaction is.

--
Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de

Is there a reason autocommit is implemented in psql and not in libpq via
a C function call?

---------------------------------------------------------------------------

Bruce Momjian wrote:

I see autocommit as implemented only in psql, not in libpq. Is that
what we want to do for 7.4?

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there a reason autocommit is implemented in psql and not in libpq via
a C function call?

One reason is that PQexec accepts multiple-query strings (possibly with
embedded BEGIN/END), so it's not immediately obvious what the semantics
ought to be. We could probably work out some reasonable definition if
we wanted to put effort into it, but seeing that libpq clients aren't
historically expecting any autocommit support, I didn't find it a high
priority task for 7.4.

At this point it's definitely too late for 7.4, anyway. Put it on the
TODO list if you feel strongly about it.

regards, tom lane

The issue I have is that every interface that relies on libpq is going
to have to code it itself. Is that OK?

---------------------------------------------------------------------------

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there a reason autocommit is implemented in psql and not in libpq via
a C function call?

One reason is that PQexec accepts multiple-query strings (possibly with
embedded BEGIN/END), so it's not immediately obvious what the semantics
ought to be. We could probably work out some reasonable definition if
we wanted to put effort into it, but seeing that libpq clients aren't
historically expecting any autocommit support, I didn't find it a high
priority task for 7.4.

At this point it's definitely too late for 7.4, anyway. Put it on the
TODO list if you feel strongly about it.

regards, tom lane

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The issue I have is that every interface that relies on libpq is going
to have to code it itself. Is that OK?

So? Most interfaces have to adhere to their own notions of transaction
semantics and control API anyway. libpq should stay out of their way
rather than try to be helpful. I see this as not different from the
lesson we learned that doing it in the backend isn't the right place.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The issue I have is that every interface that relies on libpq is going
to have to code it itself. Is that OK?

So? Most interfaces have to adhere to their own notions of transaction
semantics and control API anyway. libpq should stay out of their way
rather than try to be helpful. I see this as not different from the
lesson we learned that doing it in the backend isn't the right place.

I know Perl and jdbc do, but things like c++ and libpgeasy don't really
have a specification to follow. With the ability to check the
transaction status, it might now be easy enough to do autocommit that
having it happen in every interfaces will be ok.

-- 
  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