Re: start of transaction (was: Re: [PERFORM] Help with - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: start of transaction (was: Re: [PERFORM] Help with
Date
Msg-id 1069064165.20092.20.camel@fuji.krosing.net
Whole thread Raw
In response to Re: start of transaction (was: Re: [PERFORM] Help with count(*))  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: start of transaction  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
List pgsql-hackers
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
> Neil Conway <neilc@samurai.com> writes:
> > Hmmm... I agree this behavior isn't ideal, although I can see the case
> > for viewing this as a mistake by the application developer: they are
> > assuming that they know exactly when transactions begin, which is not
> > a feature provided by their language interface.
> 
> Well, actually, it's a bug in the interface IMHO.  But as I said in the
> last thread, it's a fairly widespread bug. 

I'm not sure that it is a client-side bug. For example Oracle seems to
_always_ have a transaction going, i.e. you can't be "outside" of
transaction, and you use just COMMIT to commit old _and_start_new_
transaction.

IIRC the same is true for DB2.

For these database the BEGIN TRANSACTION command is mainly used for
starting nested transactions, which we don't have.

> We've been taking the
> position that the interface libraries should get fixed, and that's not
> happening.  It's probably time to look at a server-side fix.

Maybe "fixing" the interface libraries would make them incompatible with
*DBC's for all other databases in some subtle ways ?

-----------------
Hannu



pgsql-hackers by date:

Previous
From: Tommi Maekitalo
Date:
Subject: Re: Release now live ...
Next
From: Hannu Krosing
Date:
Subject: Re: start of transaction (was: Re: [PERFORM] Help with