Re: 7.1 beta 3 Linux ODBC BEGIN Behaviour
От | Tom Lane |
---|---|
Тема | Re: 7.1 beta 3 Linux ODBC BEGIN Behaviour |
Дата | |
Msg-id | 3976.981826245@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour
|
Список | pgsql-interfaces |
"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
В списке pgsql-interfaces по дате отправления: