Barry Lind wrote:
The other thing that I have been meaning to say in this thread is that I
don't like using COMMIT to mean subtransaction commit (vs. introducing a
new command for it) because of the following situation.
Lets say that I have a java method that takes a jdbc connection and this
c
Barry Lind <[EMAIL PROTECTED]> writes:
> I like the functionality of nested transactions, I just think that there
> needs to be different commands other than BEGIN/COMMIT to work with
> them. So that there is no possiblity for misunderstanding what COMMIT
> really means.
There's something to b
The other thing that I have been meaning to say in this thread is that I
don't like using COMMIT to mean subtransaction commit (vs. introducing a
new command for it) because of the following situation.
Lets say that I have a java method that takes a jdbc connection and this
code starts a trans
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Did I make a mistake by promoting subtransactions rather than
> savepoints?
No. We can implement savepoints on top of subtransactions, but not
vice versa. AFAICS the savepoint syntax is just a shorthand for
a constrained form of subtransaction --- esse
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't think we should explicitly forbid it. I think it should be
> forbidden to close the outermost transaction inside a function (else the
> function would not be able to terminate correctly), but for levels
> before that one it'd be OK.
More specif
> The problem I see with moving towards supporting savepoints with the
> current proposal is with how commit works:
>
> Consider:
>
> begin;
> insert into foo values (1);
> savepoint dammit;
> insert into foo values (2);
> select foo;
> insert into foo values (3);
>
On Thu, 2004-06-17 at 02:44, Alvaro Herrera wrote:
> I don't know what Oracle or other DBMSs expect in this area. Anyone
> care to give me a few pointers? If I'm missing something, I want to
> know as soon as possible.
Without ignoring your other responses, I remain massively impressed
SAVE
Alvaro Herrera wrote:
With this in place, implementing SAVEPOINTs the way SQL expects them to
work appears to be a very trivial exercise.
You may not see it, but a savepoint is just the start of a nested
transaction in disguise. Consider:
begin;
insert into foo values (1);
savepoi
Alvaro Herrera wrote:
> On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote:
> > >And consider this case:
> > >
> > > BEGIN;
> > > ...
> > > SAVEPOINT x;
> > > SELECT func_call();
> > > SELECT func_call();
> > > COMMIT;
> > >
> > >Now if func_call has a savepoint, it
On Wed, Jun 16, 2004 at 09:36:33PM -0400, Bruce Momjian wrote:
> And consider this case:
>
> BEGIN;
> ...
> SAVEPOINT x;
> SELECT func_call();
> SELECT func_call();
> COMMIT;
>
> Now if func_call has a savepoint, it is really nested because it can't
> know whe
Christopher Kings-Lynne wrote:
> > And consider this case:
> >
> > BEGIN;
> > ...
> > SAVEPOINT x;
> > SELECT func_call();
> > SELECT func_call();
> > COMMIT;
> >
> > Now if func_call has a savepoint, it is really nested because it can't
> > know whether the savepoint X wi
On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote:
> >And consider this case:
> >
> > BEGIN;
> > ...
> > SAVEPOINT x;
> > SELECT func_call();
> > SELECT func_call();
> > COMMIT;
> >
> >Now if func_call has a savepoint, it is really nested because it can
And consider this case:
BEGIN;
...
SAVEPOINT x;
SELECT func_call();
SELECT func_call();
COMMIT;
Now if func_call has a savepoint, it is really nested because it can't
know whether the savepoint X will be used to roll back, so its status is
dependent o
On Wed, Jun 16, 2004 at 11:45:36PM +0100, Simon Riggs wrote:
> The patch looks impressively technical, but overall I'm not exactly sure
> what it does...I guess I'm just not clear why I would want it, except as
> the main technical pre-work to later syntax changes. I'm sure some short
> explanatio
Barry Lind wrote:
> I agree with Simon's comments. And to them I would add: I had assumed
> that the requirements for 'nested transactions' was following some
> standard definition or specification (i.e. the ANSI SQL spec). But from
> what I can tell, we are rolling our own definition here, n
I agree with Simon's comments. And to them I would add: I had assumed
that the requirements for 'nested transactions' was following some
standard definition or specification (i.e. the ANSI SQL spec). But from
what I can tell, we are rolling our own definition here, not following a
specificat
On Tue, 2004-06-08 at 23:23, Alvaro Herrera wrote:
> Hackers,
>
> Here is the latest installment of the nested transactions patch.
>
> What's in the current patch:
>
First of all, thank you for all your helpful comments recently.
The patch looks impressively technical, but overall I'm not exac
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it after review.
---
Alvaro Herrera wrote:
> Hackers,
>
> Here is the lates
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-05-14 at 17:40, Alvaro Herrera wrote:
>> Turns out the patch is too big and the server won't publish it.
> Is there a good reason for keeping this size limit on the -patches list?
I think Marc was more or less forced into lowering the size li
On Fri, 2004-05-14 at 17:40, Alvaro Herrera wrote:
> Turns out the patch is too big and the server won't publish it.
Is there a good reason for keeping this size limit on the -patches list?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading
On Fri, May 14, 2004 at 04:41:06PM -0400, Alvaro Herrera wrote:
> Hackers,
>
> Here is my current patch implementing nested transactions.
Turns out the patch is too big and the server won't publish it.
Meanwhile, Bruce has posted it as
ftp://candle.pha.pa.us/pub/postgresql/mypatches/nested.diff
Hackers,
Here is my current patch implementing nested transactions.
At this point I'd like some actual testing. If you have any use for
this please test it and tell me how it behaves for you. Report any
annoyances.
Still missing:
- deal with deferred triggers.
- do something with catcache refe
Newest version of this patch applied. Thanks.
---
Alvaro Herrera wrote:
> Hackers,
>
> In an attempt to simplify my life I'm submitting this patch that
> restructures the deferred trigger queue. The fundamental change is
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Alvaro Herrera wrote:
> On Wed, Jun 11, 2
24 matches
Mail list logo
