RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour

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?

Regards,
Steve

At 11:38 PM 2/9/01 +0900, Hiroshi Inoue wrote:
>> -----Original Message-----
>> From: LászlETibor
>> Sent: Friday, February 09, 2001 8:03 PM
>> To: pgsql-interfaces(at)postgresql(dot)org
>> Subject: RE: [INTERFACES] 7.1 beta 3 Linux ODBC BEGIN Behaviour
>>
>>
>> > I found another slight behavior change with the Linux
>> > client ODBC library between 7.0.3 and the 7.1 beta 3
>> > release. We are running under Redhat 6.0.
>> >
>> > We have set the ODBC driver in autocommit off mode. With
>> > the 7.0.3 driver, a BEGIN was automatically issued
>> > before the driver encountered a INSERT/UPDATE/DELETE. With
>> > the 7.1 beta 3 ODBC driver, it now also issues a BEGIN when it
>> > encounters a SELECT.
>> >
>> > Is this the expected behavior under 7.1?
>>
>> I think it can be. (We assumed this behavior a year ago.) Sometimes we
>> need transaction time in the beginning of a transaction. We can
>> get it with
>> a
>> SELECT. Because the transaction can begin only with an update statement,
>> we must do a workaround - until now.
>>
>
>Hmm, seems I committed a change too hastely.
>Hiroki Kataoka also has a similar opinion.
>
>The following statement types are in psqlodbc.h.
>Well how about "begin" before TYPE_SELECT
>etc and "commit" before TYPE_OTHER
>statements ?
>
>/* statement types */
>enum {
> STMT_TYPE_UNKNOWN = -2
> STMT_TYPE_OTHER = -1,
> STMT_TYPE_SELECT = 0,
> STMT_TYPE_INSERT,
> STMT_TYPE_UPDATE,
> STMT_TYPE_DELETE,
> STMT_TYPE_CREATE,
> STMT_TYPE_ALTER,
> STMT_TYPE_DROP,
> STMT_TYPE_GRANT,
> STMT_TYPE_REVOKE,
>};
>
>Regards,
>Hiroshi Inoue