Skip site navigation (1) Skip section navigation (2)

Re: [Re] Re: PREPARE and transactions

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-06-25 12:54:57
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AE87@Herge.rcsinc.local (view raw or whole thread)
Lists: pgsql-hackers
Jeroen wrote:
> Granted, that's probably going to force the issue.  I do wonder
> one of the arguments in favour of the current semantics is that the
> problems can be worked around using nested transactions.  Then what
> people doing before nested transactions, in Tom's scenario where the
> programmer doesn't know where transactions begin?

The trick is that with the current semantics, you don't have to watch
transaction activity, just the prepare statements.  You know if and when
(from the client/driver's point of view) a prepared statement exists
because you created it and don't have to be concerned about the

If you guys change the lifetime, it becomes difficult or impossible to
set a flag on the client which guarantees prepared statement existence.
This means I have to wrap the statement execution with a subtransaction
or run the risk of bouncing a current transaction.  Currently in the
applications I write 70% of all I/O goes through prepared
statements...the reason to do this was to reduce statement turnaround
latency, which is the main driving performance factor in COBOL

I would be fine with changing the lifetime if an EXECUTE failure did not
abort the current transaction.  Then I could simply watch the return
code of the statement execution and prepare the statement on
demand...from my point of view, this would actually be the most elegant



pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-06-25 13:25:58
Subject: Re: PREPARE and transactions
Previous:From: Jeroen T. VermeulenDate: 2004-06-25 12:18:46
Subject: Re: [Re] Re: PREPARE and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group