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-07-01 20:06:06
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AEB1@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeroen wrote:
> I see how making PREPARE obey rollbacks would be inconvenient for some
> existing code, but frankly I'm getting a bit worried about the "why
> I care whether what I do is committed or not?" argument.  I guess one
> could
> say that about lots of statements: "I don't really want this to be
> to the transaction but it happens convenient for me to write it inside
> transaction, and then I have this problem that it's affected by
> rollbacks."
> If it's that important, come up with a generic
> syntax to temporarily escape bracketing.

The big picture here is that with the current behavior, it is possible
to keep track of existence of prepared statements without wrapping or
even being aware of transaction activity.  This is tremendously useful
for handling them in a generic way because transactions and prepared
statements are handled on different levels of my (and others')
technology stack.  If you change that behavior, that is no longer
possible, period, and I will be forced to stop using them.

On the conceptual side of things, I submit that the creation and
deletion of prepared statements are much closer to session variables
than to normal imperative SQL (that normally has a transactional
lifetime).  They are an optimization hack (albeit a very handy one) much
the same as turning off sequential scans.  I tend to think of them more
as macros that I can create and destroy (and in implementation, that is
really close to what they are).



pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2004-07-01 20:10:10
Subject: A wanna be
Previous:From: Thomas SwanDate: 2004-07-01 19:01:37
Subject: Nested Transactions, Abort All

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