Re: [Re] Re: PREPARE and transactions

On Fri, Jul 02, 2004 at 08:51:05AM -0400, Merlin Moncure wrote:

> Right now, I'm transitioning to ExexPrepared to skip the string escaping
> step on the client side. I would hate to lose that ability. ExecParams
> is a little more work to set up (doable, though).

OTOH, if you're taking client code queries and replacing them with
EXECUTEs (which I sort of gathered some people were doing), all it should
really do is move the matching activity to the server...

> > Am I making things too simple here?
>
> Unfortunately, I think the answer is yes. Being able to roll back
> prepared statements would exclude them from a narrow but important class
> of use.

Wait, wait, wait! I'm talking about the pattern-matching proposal there.
The proposal means that prepared statement introduction would _not_ have
to be rolled back; only the _names_ would obey different rules. In effect
it would separate the names from the plans, and make the plans do what you
want and more. The names would be effectively obsolete.

> With the introduction of nested x into the code base, your original
> problem can be guarded against (albeit somewhat clumsily) by careful use
> of wrapping PREPARE/DEALLOCATE. If you switch things up, every EXECUTE
> has to be wrapped to guarantee safety in a transaction agnostic
> scenario.

But why should anyone insist on a "transaction agnostic scenario" yet
play with prepared statements? That seems backwards to me. Transactions
are a correctness issue, which you think about first. Prepared statements
are optimization, which though important is undoubtedly a lesser concern.
If you're deep enough into the SQL stream to analyze the client's demands
and prepare statements based on it, just knowing what happens to bracketing
(unlike prepared statements, you don't even need to control that) should be
relatively easy.

In any case, AFAICS my proposal does away with the need to wrap anything,
or keep track of transactions and/or prepared statements. Would it work
for you?

Jeroen