Thread: RE: [INTERFACES] 7.1 beta 3 Linux ODBC BEGIN Behaviour

> -----Original Message-----
> From: LászlETibor
> Sent: Friday, February 09, 2001 8:03 PM
> To: pgsql-interfaces@postgresql.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

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@postgresql.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

> -----Original Message-----
> From: Steve Wranovsky [mailto:stevew@merge.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