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
should
> 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
subject
> to the transaction but it happens convenient for me to write it inside
the
> transaction, and then I have this problem that it's affected by
> rollbacks."
> If it's that important, come up with a generic
"session-not-transaction"
> 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).
Merlin
