From: Steve Wranovsky <stevew@merge.com>
To: pgsql-interfaces@postgresql.org
To: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour
Date: Mon, 12 Feb 2001 10:37:00 -0600
Message-ID: <4.3.2.7.2.20010212102302.00bca7c0@mail.merge.com> (raw)
In-Reply-To: <EKEJJICOHDIEMGPNIFIJCEBDDJAA.Inoue@tpf.co.jp>
References: <3976.981826245@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: stevew@merge.com, pgsql-odbc@postgresql.org
Subject: Re: [ODBC] RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour
In-Reply-To: <4.3.2.7.2.20010212102302.00bca7c0@mail.merge.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox