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?
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.
>
> Fro
(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 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
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, n
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-le
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.
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 comm
-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 incom
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 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
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 trans
[ 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 manipu
> 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
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". T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
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 transac
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
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 ()
FOO MANE PADME HUM
19 matches
Mail list logo
