Also, per other discussions, we are removing backend autocommit support
in 7.4. It was the wrong way to do it.
Somehow I did not see that conclusion made.
I thought, at least for JDBC, it is already successfully used ?
I think the backend autocommit is useful. Maybe only the
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Somehow I did not see that conclusion made.
I thought, at least for JDBC, it is already successfully used ?
Barry, at least, seemed to be happy with removing it, given the planned
protocol change to report current transaction state after every
Andreas,
From the JDBC side it really doesn't make that much difference. The
JDBC code needs to support both ways of doing it (explicit begin/commits
for 7.2 and earlier servers, and set autocommit for 7.3 servers), so
however it ends up for 7.4 it shouldn't be too much work to adopt. As
Hi,
Tom Lane wrote:
It seems to me that it'd be fairly easy to make BEGIN cause only
a local state change in the backend; the actual transaction need not
start until the first subsequent command is received. It's already
true that the transaction snapshot is not frozen at BEGIN time, but
only
Olleg Samojlov [EMAIL PROTECTED] writes:
As I can remember, already, when autocommit off transaction begin with
first DML or DDL command. May be better change client to use autocommit
off mode?
We've been waiting for those clients to get fixed for a long while.
Waiting for them to adopt
On Fri, 28 Mar 2003, Tom Lane wrote:
It seems to me that it'd be fairly easy to make BEGIN cause only
a local state change in the backend; the actual transaction need not
start until the first subsequent command is received. It's already
true that the transaction snapshot is not frozen at
scott.marlowe [EMAIL PROTECTED] writes:
On Fri, 28 Mar 2003, Tom Lane wrote:
It seems to me that it'd be fairly easy to make BEGIN cause only
a local state change in the backend; the actual transaction need not
start until the first subsequent command is received. It's already
true that the
On Fri, Mar 28, 2003 at 11:13:28PM -0500, Tom Lane wrote:
The other thing that could be thought about here is when to freeze the
value of now(). Currently now() is frozen when BEGIN is received.
We could keep doing that, but it seems to me it would make more sense
to freeze now() when the
Doug McNaught wrote:
Tom Lane [EMAIL PROTECTED] writes:
Accordingly, it's a bad idea to invent now('clock') and make it the
same function as the other flavors. We could get away with making
now('transaction') and now('statement') but the argument for this
was consistency, and that
Bruce Momjian [EMAIL PROTECTED] writes:
Doug McNaught wrote:
Maybe clock_time() and statement_time(), with transaction_time() an
alias for now() (if that's seemed necessary)?
I could go with that ...
We already have CURRENT_TIMESTAMP. Would CLOCK_TIMESTAMP,
TRANSACTION_TIMESTAMP, and
A conversation with Andrew Sullivan led me to the following idea:
We have a number of frontends that like to issue BEGIN immediately
after COMMIT; so that if the client does nothing for awhile after
finishing one transaction, the backend nonetheless sees it as being
in a transaction. This
On Fri, 28 Mar 2003, Tom Lane wrote:
It seems to me that it'd be fairly easy to make BEGIN cause only
a local state change in the backend; the actual transaction need not
start until the first subsequent command is received.
[snip]
In a very real sense, the transaction snapshot defines when
12 matches
Mail list logo
