"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> There must be "SELECT ~ FOR UPDATE" of inside of the transaction.
> You are right.
> However psqlodbc has never checked "for update".
> My recent change doesn't take "for update" into
> account either.
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.
regards, tom lane
