Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f1AHV2x70632; Sat, 10 Feb 2001 12:31:02 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f1AHUj903979; Sat, 10 Feb 2001 12:30:45 -0500 (EST) To: "Hiroshi Inoue" cc: "Hiroki Kataoka" , pgsql-interfaces@postgresql.org, pgsql-odbc@postgresql.org, "Steve Wranovsky" Subject: Re: 7.1 beta 3 Linux ODBC BEGIN Behaviour In-reply-to: References: Comments: In-reply-to "Hiroshi Inoue" message dated "Sat, 10 Feb 2001 23:22:19 +0900" Date: Sat, 10 Feb 2001 12:30:45 -0500 Message-ID: <3976.981826245@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200102/81 X-Sequence-Number: 1034 "Hiroshi Inoue" 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