Dennsnippetssklund wrote:
> On Fri, 9 Jul 2004, Mike Rylander wrote:
>
>> Nested transactions and savepoints serve two different purposes. They
>> have some overlap, but for the most part solve two distinct problems.
>
> Then show some examples that illustrait the difference. So far all
> exa
Dennis Bjorklund wrote:
> On Sat, 10 Jul 2004, Mike Rylander wrote:
>
>> They do, if only to make particular constructs easier to write. This is
>> an opinion, but for example an EXCEPTION framework for plpgsql would be
>> easier to implement and use if it used the nested transactions rather
>
On 7/11/2004 12:22 AM, Alvaro Herrera wrote:
There is not a lot of difference. This was allowed in nested
transactions because we wanted the nesting be to OK when using it in a
possibly aborted transaction block, so the user would not commit a
transaction that could not have been created. In save
On 7/10/2004 6:55 PM, Josh Berkus wrote:
Bruce,
It seems anonymous savepoints really don't buy us anything. They don't
match the Oracle behavior, and don't do anything more than nested
transactions. I agree we want them, but I don't see the value they add
value right now.
Anonymous Savepoints == N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> To my current knowledge (and hopefully Andrew will speak up if I'm
> wrong) the DBD::Pg driver reports back a query exception, but not
> the SQLSTATE.
The current production driver will report back the error, but not the
SQLSTATE. The next vers
Alvaro Herrera wrote:
> On Sun, Jul 11, 2004 at 03:15:46PM -0700, Josh Berkus wrote:
>
> > For that matter:
> >
> > begin;
> > savepoint;
> > select 0/0; -- abort
> > savepoint; -- commands will be ignored
> > select 1; -- commands will be ignored
On Sun, Jul 11, 2004 at 03:15:46PM -0700, Josh Berkus wrote:
> For that matter:
>
> begin;
> savepoint;
> select 0/0; -- abort
> savepoint; -- commands will be ignored
> select 1; -- commands will be ignored
> release; -- com
On Sun, 2004-07-11 at 16:01, Josh Berkus wrote:
> Scott,
>
> > Uh, I think it can:
> >
> > http://www.php.net/manual/en/function.pg-result-error.php
>
> Heh. I half-knew that if I pointed this out that someone would correct me
> with a link to new code. In my defense, I will point out that
Alvaro,
> I have a better question: do we allow SAVEPOINT (i.e. to establish a
> savepoint, i.e. to open a nested transaction) within an aborted
> transaction block?
My opinion? No. I would personally not want to allow it.
> My opinion is that we should disallow both SAVEPOINT and RELEASE whe
Bruce,
> Do we want to allow BEGIN NESTED to start a main transaction? Oracle
> can use SAVEPOINTS all the time because it knows it is always in a
> transaction, but PostgreSQL is not always. I don't see a downside to
> allowing it. COMMIT will still commit the entire transaction, of
> course.
Scott,
> Uh, I think it can:
>
> http://www.php.net/manual/en/function.pg-result-error.php
Heh. I half-knew that if I pointed this out that someone would correct me
with a link to new code. In my defense, I will point out that the mentioned
PHP feature is less than 4 months old.
> Not a r
On Sat, 10 Jul 2004, Bruce Momjian wrote:
> Oracle can use SAVEPOINTS all the time because it knows it is always in
> a transaction, but PostgreSQL is not always.
PostgreSQL is also alsways in a transaction. If some use autocommit and go
SAVEPOINT foo;
RELEASE foo;
The first will work and
On Sat, Jul 10, 2004 at 08:25:16PM -0400, Bruce Momjian wrote:
> Do we want to allow BEGIN NESTED to start a main transaction?
I have a better question: do we allow SAVEPOINT (i.e. to establish a
savepoint, i.e. to open a nested transaction) within an aborted
transaction block?
This is allowed i
On Sat, 2004-07-10 at 15:21, Josh Berkus wrote:
> Bruce,
>
> > They have no way of reporting a failed query back to the user? How do
> > people program in those environments? Right now any failed query aborts
> > the transaction so it seems it would be pretty easy.
>
> Believe it or not, PHP4 d
Josh Berkus wrote:
> > Well, that involves either creating a conditional capability in the
> > backend, or in psql, neither of which will happen for 7.5. The best we
> > can do is allow COMMIT NESTED INGORE ERROR (or COMMIT NESTED INGORE
> > ROLLBACK) and just let the script keep going. I am think
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > It seems anonymous savepoints really don't buy us anything. They
> > don't match the Oracle behavior, and don't do anything more than
> > nested transactions. I agree we want them, but I don't see the value
> > they add value right now.
>
> The v
Josh Berkus wrote:
3) We adopt a slightly mutated form of the SQL3 SAVEPOINT syntax. This would
have the twin benefit of both allowing us to improve our standards compliance
and make savepoints completely compliant in the next version, as well as
helping those wishing to migrate from Oracle to
Bruce,
> It seems anonymous savepoints really don't buy us anything. They don't
> match the Oracle behavior, and don't do anything more than nested
> transactions. I agree we want them, but I don't see the value they add
> value right now.
Anonymous Savepoints == Nested Transactions
This issue
Bruce Momjian wrote:
> It seems anonymous savepoints really don't buy us anything. They
> don't match the Oracle behavior, and don't do anything more than
> nested transactions. I agree we want them, but I don't see the value
> they add value right now.
The value they add is that they follow the
Bruce Momjian wrote:
The syntax was for support of script languages that don't have
conditional constructs, like psql scripts, where you want the subxact to
commit but if it fails, you don't want that to affect the outer
transaction. Are you saying there are very few cases where you don't
care if
Josh Berkus wrote:
> But the ability to detect an abort state *from the SQL command line*
> (or a database port connection) has not been addressed.
This has existed since 7.4. If some interfaces don't expose it, fix
those interfaces.
---(end of broadcast)-
Josh Berkus wrote:
> Bruce,
>
> > They have no way of reporting a failed query back to the user? How do
> > people program in those environments? Right now any failed query aborts
> > the transaction so it seems it would be pretty easy.
>
> Believe it or not, PHP4 doesn't. This is one of the
Josh Berkus wrote:
> Dennis,
>
> > The non-standard part I was talking about was the savepoints without
> > names, and that is what we should support for ever if we introduce them.
>
> I don't have a problem with that idea.Anonymous Savepoints should be easy
> to support if we are supportin
Dennis,
> The non-standard part I was talking about was the savepoints without
> names, and that is what we should support for ever if we introduce them.
I don't have a problem with that idea.Anonymous Savepoints should be easy
to support if we are supporting Named (spec) Savepoints. And t
Bruce,
> They have no way of reporting a failed query back to the user? How do
> people program in those environments? Right now any failed query aborts
> the transaction so it seems it would be pretty easy.
Believe it or not, PHP4 doesn't. This is one of the reasons why coders in
other lang
Josh Berkus wrote:
> Bruce,
>
> > Well, Oracle doesn't suppor RELEASE, so we are matching the standard but
> > perhaps not allowing easy migration from Oracle.
>
> Well, that's Oracle's problem. Considering the amount of influence they had
> over the standard, there's no excuse for their syntax
Bruce,
> Well, Oracle doesn't suppor RELEASE, so we are matching the standard but
> perhaps not allowing easy migration from Oracle.
Well, that's Oracle's problem. Considering the amount of influence they had
over the standard, there's no excuse for their syntax. Also, if someone
converts
I just posted a clarification. It isn't a problem.
---
Josh Berkus wrote:
> Dennis, Bruce,
>
> > Just to clarify, this is to allow rolling back to the same savepoint
> > multiple times. If we named savepoints, the new sav
On Sat, 10 Jul 2004, Bruce Momjian wrote:
> > > > SAVEPOINT == BEGIN NESTED
> > > > RELEASE SAVEPOINT == COMMIT NESTED
> > > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
> > >
> > > Here it should be:
> > >
> > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
> >
Bruce Momjian wrote:
> Dennis Bjorklund wrote:
> > On Sat, 10 Jul 2004, Josh Berkus wrote:
> >
> > > In other words:
> > > SAVEPOINT == BEGIN NESTED
> > > RELEASE SAVEPOINT == COMMIT NESTED
> > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
> >
> > Here it should be:
> >
> > ROLLBACK TO SA
Dennis, Bruce,
> Just to clarify, this is to allow rolling back to the same savepoint
> multiple times. If we named savepoints, the new savepoint would be the
> same name as the one we just rolled back.
Hmmm ... yeah, it would be nice to find a way around this so that we don't
have non-standard
Dennis Bjorklund wrote:
> On Sat, 10 Jul 2004, Josh Berkus wrote:
>
> > In other words:
> > SAVEPOINT == BEGIN NESTED
> > RELEASE SAVEPOINT == COMMIT NESTED
> > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
>
> Here it should be:
>
> ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT
Josh Berkus wrote:
> If you couldn't tell, I favor option 3) b)This syntax would look like:
>
> BEGIN TRANSACTION; --begin main
> do stuff;
> SAVEPOINT; -- begin "nested transaction 1"
> do more stuff;
> SAVEPOINT; -- begin "nested transaction 2" inside
On Sat, 10 Jul 2004, Josh Berkus wrote:
> In other words:
> SAVEPOINT == BEGIN NESTED
> RELEASE SAVEPOINT == COMMIT NESTED
> ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
Here it should be:
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
And just to clearify, this is an ex
On Sat, Jul 10, 2004 at 09:46:00PM +0200, Dennis Bjorklund wrote:
> One can have many different semantics, here are 3 versions:
>
> 1) You release savepoints in any order
> 2) You release savepoints in reverse order
> 3) You release any savepoints and later ones then the
> one you released
People,
Are we perhaps getting away from the issues here? The reason for this
discussion was to determine the user-level syntax for Alvaro's nested
transactions. We can discuss all we want about how he should have maybe
implemented some things differently, but we're supposed to start beta-t
On Sat, 10 Jul 2004, Alvaro Herrera wrote:
> That's why it's absurd. Why allow an operation which isn't really an
> operation?
Same reason why you allow an addition with 0. One can say that it's
not really an operation either.
One can have many different semantics, here are 3 versions:
1) Yo
On Fri, Jul 09, 2004 at 08:03:36PM +0100, Simon Riggs wrote:
> On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
> > So this is another reason why we should use COMMIT to close a nested
> > transaction: it may refer to a transaction that is already closed
> > because the user got confused.
Sorry
On Sat, Jul 10, 2004 at 06:22:00PM +0200, Dennis Bjorklund wrote:
> On the other hand, it's not hard to implement the other behaviour either
> if that is what one wants (and we don't). It would only forget the name of
> the earlier savepoint. The corresponding transaction in itself have to
> stay.
On Sat, 10 Jul 2004, Tom Lane wrote:
> Nonsense. Invalidating an older savepoint must invalidate everything
> after it as well. The fact that the savepoint syntax allows you to
> express conceptually-ridiculous operations (like that one) is not a
> point in its favor IMHO.
Luckily the standard
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Fri, 9 Jul 2004, Mike Rylander wrote:
>> Nested transactions and savepoints serve two different purposes. They have
>> some overlap, but for the most part solve two distinct problems.
> Then show some examples that illustrait the difference. So fa
On Sat, 10 Jul 2004, Mike Rylander wrote:
> They do, if only to make particular constructs easier to write. This is an
> opinion, but for example an EXCEPTION framework for plpgsql would be easier
> to implement and use if it used the nested transactions rather than
> savepoint syntax:
>
> CREAT
Alvaro Herrera wrote:
On Sat, Jul 10, 2004 at 09:46:56AM +1200, Oliver Jowett wrote:
Alvaro Herrera wrote:
We can't actually release anything (commit the subtransactions), because
they may be savepoints established after that point, and they are
logically "inside" the previously established ones.
Bruce Momjian wrote:
Interesting Oracle doesn't support RELEASE or savepoint levels:
T271, SavepointsOracle supports this feature, except:
* Oracle does not support RELEASE SAVEPOINT.
Yes, and IMHO it's just some housekeeping stuff, informing the backend
that you'll never want to rol
Simon Riggs wrote:
BEGIN
display one screen to user - book the flight
INSERT INTO ...
INSERT INTO ...
UPDATE ...
SAVEPOINT
display another related screen - book the hotel
INSERT INTO
DELETE
UPDAT
On Sat, 10 Jul 2004, Gavin Sherry wrote:
> "3) The savepoint identified by S and all savepoints established in the
> current savepoint level subsequent to the establishment of S are
> destroyed."
So the standard savepoints are even more like the subtransactions that
alvaro have implemented then I
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> On Fri, Jul 09, 2004 at 11:28:23PM +0200, Dennis Bjorklund wrote:
> > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> >
> > > Yes, we free some things. Granted it's not a lot, but we have stacks
> > > for several things that will be always be growing with s
On Fri, 9 Jul 2004, Mike Rylander wrote:
> Nested transactions and savepoints serve two different purposes. They have
> some overlap, but for the most part solve two distinct problems.
Then show some examples that illustrait the difference. So far all
examples shown that uses subtransactions co
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> I mean this:
>
> begin;
> ... work ...;
> savepoint foo;
> ... more work ...;
> savepoint bar;
> ... yet more ... ;
> release foo;
>
>
> At this time I can't release savepoint foo because the implementation
> (nested) requires me to keep i
On Sat, Jul 10, 2004 at 09:46:56AM +1200, Oliver Jowett wrote:
> Alvaro Herrera wrote:
>
> >We can't actually release anything (commit the subtransactions), because
> >they may be savepoints established after that point, and they are
> >logically "inside" the previously established ones. At RELEA
On Fri, Jul 09, 2004 at 11:28:23PM +0200, Dennis Bjorklund wrote:
> On Fri, 9 Jul 2004, Alvaro Herrera wrote:
>
> > Yes, we free some things. Granted it's not a lot, but we have stacks
> > for several things that will be always be growing with savepoints,
>
> They will not always be growing for
Min Xu (Hsu) wrote:
> Dear all,
>
> I've being following the discussion of the nested transaction. I
> apologize for that I can't help asking my questions as I get more
> confused about what exactly are nested transactions, at least as far as
> the concurrency control goes.
>
> It seems to me
Oliver Jowett wrote:
The 2003 draft claims that RELEASE SAVEPOINT invalidates savepoints
subsequent to the RELEASE:
"subsequent to the released savepoint" rather.
-O
---(end of broadcast)---
TIP 6: Have you searched our list archives?
h
Dennis Bjorklund wrote:
> On Fri, 9 Jul 2004, Bruce Momjian wrote:
>
>> I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
>> TRANSACTION and COMMIT NESTED TRANSACTION.
>
> Should I read this as pg will get its own implementation of sub
> transactions and not implement the almost
Alvaro Herrera wrote:
We can't actually release anything (commit the subtransactions), because
they may be savepoints established after that point, and they are
logically "inside" the previously established ones. At RELEASE we can't
really release -- we just lose the name and thus the opportunity
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> Yes, we free some things. Granted it's not a lot, but we have stacks
> for several things that will be always be growing with savepoints,
They will not always be growing for savepoints, you can free things when
using savepoints just as with subtransac
Dear all,
I've being following the discussion of the nested transaction. I
apologize for that I can't help asking my questions as I get more
confused about what exactly are nested transactions, at least as far as
the concurrency control goes.
It seems to me there are two different types of nest
Alvaro Herrera wrote:
On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
visibility issue and how far do you unwind the depth of subtransactions
or transactions?
BEGIN
UPDATE A
SAVEPOINT X
BEGIN
BEGIN
UPDATE B
BEGIN
UPDATE C
ROLLBACK TO SAVEPOINT X
What hap
On Fri, Jul 09, 2004 at 04:07:19PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > We can't actually release anything (commit the subtransactions), because
> > they may be savepoints established after that point, and they are
> > logically "inside" the previously established ones. At RELE
Simon Riggs wrote:
> On Fri, 2004-07-09 at 21:18, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > >
> > > Oracle uses ROLLBACK TO SAVEPOINT...identical pretty much.
> >
> > I thouht ROLLBACK was different from RELEASE, no? I see ROLLBACK used
> > in SQL99 for savepoints:
> >
> > ROLLBAC
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> > Simon posted it. It is called RELEASE:
>
> We can't actually release anything (commit the subtransactions), because
> they may be savepoints established after that point, and they are
> logically "inside" the previously established ones. At RELEASE
On Fri, 2004-07-09 at 21:18, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > Oracle uses ROLLBACK TO SAVEPOINT...identical pretty much.
>
> I thouht ROLLBACK was different from RELEASE, no? I see ROLLBACK used
> in SQL99 for savepoints:
>
> ROLLBACK [ WORK ] [ AND [ NO ] CHAIN ]
>
Simon Riggs wrote:
> On Fri, 2004-07-09 at 20:34, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> > > > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> > > >
> > > > > Clearly savepoints do not allow for a snapshot to be released
Alvaro Herrera wrote:
> On Fri, Jul 09, 2004 at 03:34:47PM -0400, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> > > > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> > > >
> > > > > Clearly savepoints do not allow for a snapsho
On Fri, 2004-07-09 at 20:34, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> > > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> > >
> > > > Clearly savepoints do not allow for a snapshot to be released; nested
> > > > xacts do.
> >
On Fri, Jul 09, 2004 at 03:34:47PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> > > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> > >
> > > > Clearly savepoints do not allow for a snapshot to be released; nested
> > > > x
Alvaro Herrera wrote:
> On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> > On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> >
> > > Clearly savepoints do not allow for a snapshot to be released; nested
> > > xacts do.
> >
> > Why not?
>
> What is it?
Simon posted it. It is called
On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
> On Fri, 9 Jul 2004, Alvaro Herrera wrote:
>
> > Clearly savepoints do not allow for a snapshot to be released; nested
> > xacts do.
>
> Why not?
What is it?
--
Alvaro Herrera ()
"Pensar que el espectro que vemos es ilusorio no
On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
> On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
>
> > visibility issue and how far do you unwind the depth of subtransactions
> > or transactions?
> >
> > BEGIN
> > UPDATE A
> > SAVEPOINT X
> > BEGIN
> >BEGIN
> > UPDAT
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> Clearly savepoints do not allow for a snapshot to be released; nested
> xacts do.
Why not?
> OTOH savepoints are trivial to implement once nested xacts are in place.
> They are only syntactic sugar.
Not only, but simple yes. I'm just opposed to having
On Fri, Jul 09, 2004 at 07:10:06PM +0200, Dennis Bjorklund wrote:
> On Fri, 9 Jul 2004, Bruce Momjian wrote:
>
> > I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
> > TRANSACTION and COMMIT NESTED TRANSACTION.
>
> Should I read this as pg will get its own implementation of sub
>
On Fri, 2004-07-09 at 11:45, Andreas Pflug wrote:
> Simon Riggs wrote:
>
> >ISTM - my summary would be
> >1. We seem to agree we should support SAVEPOINTs
> >
> >2. We seem to agree that BEGIN/COMMIT should stay unchanged...
> >
> >
> >
> >>With savepoints, it looks pretty strange:
> >>
> >>
On Fri, 9 Jul 2004, Bruce Momjian wrote:
> I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
> TRANSACTION and COMMIT NESTED TRANSACTION.
Should I read this as pg will get its own implementation of sub
transactions and not implement the almost equivalent standard (sql99)
savepoint
Pavel Stehule wrote:
> >
> > An 'END SUB' after a 'BEGIN SUB' in plpgsql could be required, and could
> > mean start/end block and subtx. I do not really see a downside.
> > But, it would imho only make sense if the 'END SUB' would commit sub
> > or abort sub iff subtx is in aborted state (see my
>
> An 'END SUB' after a 'BEGIN SUB' in plpgsql could be required, and could
> mean start/end block and subtx. I do not really see a downside.
> But, it would imho only make sense if the 'END SUB' would commit sub
> or abort sub iff subtx is in aborted state (see my prev posting)
>
> Andreas
>
H
On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
> visibility issue and how far do you unwind the depth of subtransactions
> or transactions?
>
> BEGIN
> UPDATE A
> SAVEPOINT X
> BEGIN
>BEGIN
> UPDATE B
> BEGIN
>UPDATE C
>ROLLBACK TO SAVEPOINT X
What
Andreas Pflug wrote:
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT x1;
INSERT INTO ...;
SAVEPOINT x2;
IN
> >But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
> >statement block. Are we intending to change that ? I think not.
> >
> >
> >
> There are two possibilities:
> Either BEGIN *does* start a subtransaction, or BEGIN does not. I don't
> see how two nesting level hierarchie
Zeugswetter Andreas SB SD wrote:
I'd opt for BEGIN as a start of a subtransaction (no need for special
semantics in plpgsql), the corresponding END simply changes the
transaction context to the parent level.
But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
statement blo
> I'd opt for BEGIN as a start of a subtransaction (no need for special
> semantics in plpgsql), the corresponding END simply changes the
> transaction context to the parent level.
But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
statement block. Are we intending to change
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT x1;
INSERT INTO ...;
SAVEPOINT x2;
INS
> As far as implementing only savepoints, look at this:
>
> BEGIN;
> BEGIN;
> INSERT INTO ...;
> COMMIT;
> BEGIN;
> INSERT INTO ...;
> COMMIT;
> BEGIN;
> INSERT INTO ...;
> COMMIT;
>
> With savepoints, it looks pretty strange:
>
> BEGI
> My proposal would be:
>
> 1. Begin main transaction: BEGIN { TRANSACTION | WORK }
> 2. Commit main (all) transaction: COMMIT { TRANSACTION | WORK }
> 3. Rollback main (all) transaction: ROLLBACK { TRANSACTION }
>
> 4. Begin inner transaction: BEGIN NESTED { TRANSACTION | WORK }
> 5. Commit inn
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
> With savepoints, it looks pretty strange:
>
> BEGIN;
> SAVEPOINT x1;
> INSERT INTO ...;
> SAVEPOINT x2;
> INSERT INTO ...;
>
Alvaro Herrera wrote:
> On Thu, Jul 08, 2004 at 10:40:36AM -0700, Josh Berkus wrote:
>
> > This means that we CANNOT maintain compatibility with other databases without
> > supporting SAVEPOINT syntax, which we are not yet ready to do. As a result,
> > I would propose the following syntax:
> >
Alvaro,
> My proposal would be:
>
> 1. Begin main transaction: BEGIN { TRANSACTION | WORK }
> 2. Commit main (all) transaction: COMMIT { TRANSACTION | WORK }
> 3. Rollback main (all) transaction: ROLLBACK { TRANSACTION }
>
> 4. Begin inner transaction: BEGIN NESTED { TRANSACTION | WORK }
> 5. Commi
On Thu, Jul 08, 2004 at 10:40:36AM -0700, Josh Berkus wrote:
> This means that we CANNOT maintain compatibility with other databases without
> supporting SAVEPOINT syntax, which we are not yet ready to do. As a result,
> I would propose the following syntax:
>
> Begin main transaction: BEGI
Alvaro, Hackers:
I've been giving this some thought. Here's what I came up with:
We should NOT use the savepoint syntax. Alvaro's Nested Transactions are not
savepoints, they don't meet the spec, and they don't behave the same. Using
standard syntax for a non-standard feature will, in my o
Scott Marlowe wrote:
On Tue, 2004-07-06 at 23:36, Greg Stark wrote:
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
Why not rollback all or commit all?
I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
f
On Wed, 2004-07-07 at 00:16, Dennis Bjorklund wrote:
> On Tue, 6 Jul 2004, Alvaro Herrera wrote:
>
> > We can later implement savepoints, which will have "SAVEPOINT foo" and
> > "ROLLBACK TO foo" as interface. (Note that a subtransaction is slightly
> > different from a savepoint, so we can't use
On Tue, 2004-07-06 at 23:36, Greg Stark wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
>
> > Why not rollback all or commit all?
> >
> > I really really don't like subbegin and subcommit. I get the feeling
> > they'll cause more problems we haven't foreseen yet, but I can't put my
> > fing
Dennis Bjorklund wrote:
Also, how do you get an anonymous subtransaction? SAVEPOINT syntax would
seem to always require a name.
Yes, it does. But surely they can be nested so an inner use of name foo
hides an outer use of name foo. I'm not pretending to know all about the
standard savepoints, so
On Wed, 7 Jul 2004, Oliver Jowett wrote:
> > If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
> > foo; followed by a RELEASE SAVEPOINT foo;
>
> Ugh.. nasty syntax and an extra empty transaction.
If you translate it directly using only the primitives of the current
subbegi
Dennis Bjorklund wrote:
On Wed, 7 Jul 2004, Oliver Jowett wrote:
So how do you propose supporting simple rollback of a subtransaction? It
seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOI
On Wed, 7 Jul 2004, Oliver Jowett wrote:
> So how do you propose supporting simple rollback of a subtransaction? It
> seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOINT foo;
--
/Denni
Dennis Bjorklund wrote:
On Wed, 7 Jul 2004, Oliver Jowett wrote:
Savepoint "ROLLBACK TO foo" doesn't invalidate 'foo'. If "SAVEPOINT foo"
is 'start new subtransaction foo', "ROLLBACK TO foo" must be 'roll back
subtransaction foo and all children; start new subtransaction foo'.
If that is all th
On Wed, 7 Jul 2004, Oliver Jowett wrote:
> Savepoint "ROLLBACK TO foo" doesn't invalidate 'foo'. If "SAVEPOINT foo"
> is 'start new subtransaction foo', "ROLLBACK TO foo" must be 'roll back
> subtransaction foo and all children; start new subtransaction foo'.
If that is all there is, I much rat
Dennis Bjorklund wrote:
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have "SAVEPOINT foo" and
"ROLLBACK TO foo" as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK TO in
subtransactions because that
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
> We can later implement savepoints, which will have "SAVEPOINT foo" and
> "ROLLBACK TO foo" as interface. (Note that a subtransaction is slightly
> different from a savepoint, so we can't use ROLLBACK TO in
> subtransactions because that has a different
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Why not rollback all or commit all?
>
> I really really don't like subbegin and subcommit. I get the feeling
> they'll cause more problems we haven't foreseen yet, but I can't put my
> finger on it.
Well I've already pointed out one problem. It m
1 - 100 of 211 matches
Mail list logo
