From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Steve Wranovsky" <stevew(at)merge(dot)com> |
Cc: | "L? zl?Tibor" <ltibor(at)mail(dot)tiszanet(dot)hu>, <kataoka(at)interwiz(dot)koganei(dot)tokyo(dot)jp>, <pgsql-interfaces(at)postgresql(dot)org>, <pgsql-odbc(at)postgresql(dot)org> |
Subject: | RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour |
Date: | 2001-02-09 23:10:57 |
Message-ID: | EKEJJICOHDIEMGPNIFIJMEPFDIAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces pgsql-odbc |
> -----Original Message-----
> From: Steve Wranovsky [mailto:stevew(at)merge(dot)com]
>
> I would think you when a standard SELECT is issued, you would not want to
> have a BEGIN, however, when a SELECT FOR UPDATE is issued, you may want
> to issue the BEGIN in this case.
>
> Is it easy to discriminate between these types of selects to
> decide when to
> do the begin?
>
Unfortunately no(at least for me).
The simplest solution is to simply issue BEGIN for all statements
in autocommit off mode if transaction isn't in progress.
However there are some commands(VACUUM etc) that couldn't
be executed inside transaction blocks.
Regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-10 02:47:32 | Re: Plan for straightening out the include-file mess |
Previous Message | Steve Wranovsky | 2001-02-09 16:55:01 | RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-02-09 23:30:07 | 6.2 protocol |
Previous Message | Steve Wranovsky | 2001-02-09 16:55:01 | RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour |