Tom Lane wrote:
Actually, no, I'd prefer not to make such a distinction; I'd be happy
with SQL-level PREPARE being nontransactional. I'd be willing to put
up with that distinction if someone shows it's needed, but so far
there's not been a really good argument advanced for it, has there?
Has
On Sun, May 02, 2004 at 10:08:50AM +1200, Oliver Jowett wrote:
If PREPARE can roll back, the driver must maintain a set of all
statements that were sucessfully PREPAREd in the current transaction,
and fix up the corresponding query object state whenever a transaction
rolls back.
From
(I'm not on -hackers, but saw this in the archives)
Alvaro Herrera wrote:
On Fri, Apr 30, 2004 at 09:44:52PM -0400, Tom Lane wrote:
Alvaro Herrera alvherre ( at ) dcc ( dot ) uchile ( dot ) cl writes:
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
prepare.c
On Tue, May 04, 2004 at 12:03:16AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Right. But note that Tom wants to distinguish between statements
created via PREPARE (which would rollback) from those created via a
Prepare message (which wouldn't).
Actually, no, I'd
On Sat, May 01, 2004 at 10:16:56PM -, Greg Sabino Mullane wrote:
We could imagine that once we add tracking of plan dependencies,
detection of a change that invalidates a prepared statement's plan
would just cause the prepared statement to be marked as needs
recompilation. The next
On Sat, May 01, 2004 at 10:16:56PM -, Greg Sabino Mullane wrote:
I am very uneasy about this. Statements should stay invalidated, else
the prepared statement may no longer even do what was originally
intended when it was first created.
I think Greg's concern is overblown, and would result
[ WRT/ automagically re-parsing prepared statement from source when
dependency
plan changes.]
If done, this would have the wonderful side-effect of being able to use
regular queries
in plpgsql procedures which must currently be done using the EXECUTE
form, such
as those that just need to
Tom Lane [EMAIL PROTECTED] writes:
Before jumping into doing that, though, I'd want to have some
discussions about the implications for the V3 protocol's notion of
prepared statements. The protocol spec does not say anything that
would suggest that prepared statements are lost on
On Mon, May 03, 2004 at 03:18:37PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Before jumping into doing that, though, I'd want to have some
discussions about the implications for the V3 protocol's notion of
prepared statements. The protocol spec does not say anything
On Tue, May 04, 2004 at 01:22:53AM -, Greg Sabino Mullane wrote:
What about rolling prepares back if they are in a transaction, though?
They still have the ability to affect a transaction, despite being
partially outside of it:
[example ripped]
IMHO this is an oversight, not a design
On Mon, May 03, 2004 at 04:15:10PM -0400, Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see how this collides with the ideas presented so far. The JDBC
driver wants the same: they want to prepare some statements and be able
to use them later in the session. They
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see how this collides with the ideas presented so far. The JDBC
driver wants the same: they want to prepare some statements and be able
to use them later in the session. They don't want to be paying
attention to which prepares were committed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If we re-parse from source then we will detect any changes that make the
query visibly incorrect. I don't really see that the user can have any
beef if he continues to use a prepared statement whose source text would
have a valid but
Alvaro Herrera [EMAIL PROTECTED] writes:
Right. But note that Tom wants to distinguish between statements
created via PREPARE (which would rollback) from those created via a
Prepare message (which wouldn't).
Actually, no, I'd prefer not to make such a distinction; I'd be happy
with SQL-level
On Fri, Apr 30, 2004 at 09:44:52PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
prepare.c probably should have provisions for rolling back its state to
the start of a failed transaction ...
Alvaro Herrera [EMAIL PROTECTED] writes:
Right now there is no distinction between a PREPARE prepared statement
and a protocol-level one. If we want to have the v3proto's statements
behave different from PREPARE's, it's just a matter of adding a new
field into the PreparedStatement.
It just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hackers,
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
alvherre=# begin;
BEGIN
alvherre=# prepare tres as select 3;
PREPARE
alvherre=# rollback;
ROLLBACK
alvherre=# execute tres;
?column?
--
3
(1 fila)
--
Alvaro Herrera
Alvaro Herrera [EMAIL PROTECTED] writes:
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
prepare.c probably should have provisions for rolling back its state to
the start of a failed transaction ... but it doesn't.
Before jumping into doing that, though, I'd
19 matches
Mail list logo
