Skip site navigation (1) Skip section navigation (2)

Re: [ODBC] RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour

From: Steve Wranovsky <stevew(at)merge(dot)com>
To: <pgsql-interfaces(at)postgresql(dot)org>, <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: [ODBC] RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour
Date: 2001-02-12 16:37:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfacespgsql-odbc
At 06:37 AM 2/11/01 +0900, Hiroshi Inoue wrote:
>> -----Original Message-----
>> From: Tom Lane
>> It'd be nice if ODBC could distinguish SELECT FOR UPDATE from plain
>> SELECT, but in practice it cannot reliably do so.  Doubtless we could
>> extend ODBC to look for "FOR UPDATE" in the text of the query, but
>> that will only catch simple situations.  Consider these possibilities:
>> * A view or rule invoked by the query uses FOR UPDATE.  (Pre-7.1, we
>> didn't support FOR UPDATE in views ... but we do now.)
>> * A function invoked by the query does SELECT FOR UPDATE internally.
>> For that matter, it's quite possible for a function invoked by a SELECT
>> to do INSERT/UPDATE/DELETE internally.  Therefore, it's impossible for
>> the ODBC driver to reliably distinguish a pure SELECT from a SELECT that
>> causes locking or even data updates.
>> Given these considerations, I think it's a mistake for ODBC to treat
>> SELECT differently from other queries for the purpose of setting
>> transaction boundaries.
>OK, agreed. 
>However simply putting back the behabior make it impossible to call
>VACUUM in psqlodbc autocommit off mode.
>My idea is as follows.
> [In autocommit off mode]
> 1) All statements except STMT_TYPE_OTHER issue
>     "BEGIN" if a trasaction isn't in progress.
> 2) STMT_TYPE_OTHER statements automatically issue
>    "COMMIT" if a transaction is progress.
>Comments ?

I now agree with point 1 above, but for point 2, I believe you should
force the user to issue a COMMIT if a transaction is in progress
when they try a VACUUM ANALYZE.  I don't think it is safe to have 
the driver issue a COMMIT for the user, mainly because it could end 
up hiding programming mistakes in that the user has failed to issue
a COMMIT, or even a ROLLBACK in their code. 


In response to


pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2001-02-12 23:16:32
Subject: Re: [ODBC] RE: 7.1 beta 3 Linux ODBC BEGINBehaviour
Previous:From: Dave PageDate: 2001-02-12 14:48:26
Subject: RE: Re: RE: [PATCHES] Re: [HACKERS] 6.2 protocol

pgsql-interfaces by date

Next:From: Bruce MomjianDate: 2001-02-12 17:25:37
Subject: Re: Re: PostgreSQL and PHP persistent connections
Previous:From: Christopher MastoDate: 2001-02-12 16:04:23
Subject: Re: An strftime function, and function name question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group