Thread: Using auto-commit OFF for transactions - instead of BEGIN

Hello

I ported a relatively simple application using Oracle 8i with a JDBC client
to PostgreSQL 7.4 with the same JDBC client, and everything just worked!

One thing that did come to light was that PG offers a proprietary 'BEGIN'
statement as a means of controlling transactions.

With Oracle, I was used to setting auto-commit to false at the start of a
transaction, and then calling commit or rollback at the end.

Is it safe for me to continue setting auto-commit to false for transactions,
and are there any compelling reasons - significant performance gains,
perhaps - why I might want to consider adopting PG's 'BEGIN' statement
instead?

Many thanks in anticipation.

Harry Mantheakis
London, UK

> I ported a relatively simple application using Oracle 8i with a JDBC
client
> to PostgreSQL 7.4 with the same JDBC client, and everything just worked!

Great.  There must not have been any blobs!  Going the other way often
creates problems because Oracle allows only one LONG field in a table, but
PG allows multiple TEXT fields.  Also, Oracle names are more restrictive and
shorter.

> With Oracle, I was used to setting auto-commit to false at the start of a
> transaction, and then calling commit or rollback at the end.
>
> Is it safe for me to continue setting auto-commit to false for
transactions,
> and are there any compelling reasons - significant performance gains,
> perhaps - why I might want to consider adopting PG's 'BEGIN' statement
> instead?

That should be the way it's done all right.  Turn it off and you can assume
that your connections will be ready with an implicit begin transaction, so
all you have to do is commit/rollback.  After that, an implicit begin occurs
for you.

David