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.
Steve
