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 ==
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
posted mailed
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
posted mailed
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
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 real
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.
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 when
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 the
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; -- commands
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
-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
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
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 savepoints,
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
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
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
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.
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:
CREATE
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 far all
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 was
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 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! I
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) You
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
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 are
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
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 NT 1
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;
And just
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
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 SAVEPOINT == ROLLBACK
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;
And just to
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
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
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,
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
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
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 supporting Named
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 reasons
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
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
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 SQL
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 is
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
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 value they
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 thinking of
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 doesn't.
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
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
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 inner
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:
BEGIN;
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;
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
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
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 hierarchies in a
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;
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 happens
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
Hello,
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 prev
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
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:
BEGIN;
SAVEPOINT
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, 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, 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
UPDATE B
BEGIN
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 (alvherre[a]dcc.uchile.cl)
Pensar que el espectro que
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 RELEASE:
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
xacts do.
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
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
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?
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 there
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
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 RELEASE we
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 it open as
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
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. Commit inner
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:
Begin
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 foo in
subtransactions because that has a different
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 foo in
subtransactions because that
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 rather see
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;
--
/Dennis
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
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
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
finger on it.
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 ROLLBACK
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
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when this is the case?
I'm not sure I understand you. Of course you can issue begin/end. What
you can't do is issue
Alvaro Herrera wrote:
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
What I'd like to do is start the transaction block before the function
is called if we are not in a transaction block. This would mean that
when the function calls BEGIN it won't be
On Tue, Jul 06, 2004 at 11:37:18AM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
What I'd like to do is start the transaction block before the function
is called if we are not in a transaction
On Tue, Jul 06, 2004 at 08:15:14AM +0200, Dennis Bjorklund wrote:
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when this is the case?
I'm not sure I understand you.
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
We could use BEGIN NESTED for starting a subtransaction, roll it back
with ROLLBACK NESTED or some such, and commit with COMMIT NESTED. But I
like SUBBEGIN etc best, and no one had an opinion when I asked. So the
current code has SUBBEGIN,
On Tue, Jul 06, 2004 at 12:49:46PM -0400, Stephen Frost wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
We could use BEGIN NESTED for starting a subtransaction, roll it back
with ROLLBACK NESTED or some such, and commit with COMMIT NESTED. But I
like SUBBEGIN etc best, and no one had an
On Tue, 2004-07-06 at 10:25, Alvaro Herrera wrote:
On Tue, Jul 06, 2004 at 08:15:14AM +0200, Dennis Bjorklund wrote:
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when
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 makes it
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
What I'd like to do is start the transaction block before the function
is called if we are not in a transaction block. This would mean that
when the function calls BEGIN it won't be the first one -- it will
Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
This seems like a non-starter to me. That would make it impossible to write
SQL generic code
Alvaro Herrera [EMAIL PROTECTED] writes:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
This seems like a non-starter to me. That would make it impossible to write
SQL generic code that could be
Greg Stark [EMAIL PROTECTED] writes:
This seems like a irregularity in the API that makes sense only from an
implementation point of view.
You are attacking a straw man. This does *not* make sense from an
implementation point of view --- it's easier to have just one command
(and in fact that
Tom Lane wrote:
Mike Benoit [EMAIL PROTECTED] writes:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
But then we're back to
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
Question: with the new syntax, would issuing a BEGIN inside a already
started transaction result in an error?
My concern is about say, a pl/pgsql
On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
Question: with the new syntax, would issuing a BEGIN inside a already
started
1 - 100 of 200 matches
Mail list logo
