Skip site navigation (1) Skip section navigation (2)

Re: Nested transactions

From: Barry Lind <blind(at)xythos(dot)com>
To: simon(at)2ndquadrant(dot)com
Cc: Patches <pgsql-patches(at)postgresql(dot)org>, alvherre(at)dcc(dot)uchile(dot)cl
Subject: Re: Nested transactions
Date: 2004-06-17 00:59:43
Message-ID: 40D0ECFF.2070501@xythos.com (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-patches
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 
specification or standard, and not following any of the other major 
commercial databases lead.

I think venturing out on our own and inventing new symantics for 
transactions and sql syntax to support them without giving this a lot of 
thought is bound to lead to problems.

Perhaps I am completely wrong here and there is a clear standard or spec 
that is being implemented, if so, please let me know what that is as it 
would help me in better understanding this patch.

I have been reviewing what Oracle does in this area and it doesn't at 
all resemble what this patch is exposing (especially as far as syntax 
goes).  I plan to look at DB2 and MSSQL next.

thanks,
--Barry



Simon Riggs wrote:
> 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 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
> explanations would clear that up for me very quickly... :)
> 
> The Todo items were:
> -Allow savepoints / nested transactions
> -Use nested transactions to prevent syntax errors from aborting a
> transaction
> 
> both of which I thought I understood:
> 
> The first one provides the SQL commands SAVEPOINT and ROLLBACK TO
> SAVEPOINT as with Oracle/DB2, and also now ANSI SQL if I recall...
> 
> The second one again provides Oracle/DB2 support by conforming to their
> interpretation of the ANSI transactional semantics definition. i.e. one
> statement failure doesn't roll back the transaction, just the statement
> that failed.
> 
> Being able to issue multiple BEGIN/END pairs isn't really (to me) the
> same thing as the above, nor do I understand why I'd ever want to do
> that - especially down to N levels....
> 
> Perhaps what I've just asked about is trivial icing on the cake you've
> just baked, so forgive me, but could you explain the outward form of
> your work and what that gives me? (or at least...what you think it gives
> you...which I accept may be different)
> 
> Best regards, Simon Riggs
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org


In response to

Responses

pgsql-patches by date

Next:From: Claudio NatoliDate: 2004-06-17 01:00:13
Subject: Re: pg_ctl service integration for WIN32
Previous:From: Simon RiggsDate: 2004-06-16 22:45:36
Subject: Re: Nested transactions

pgsql-jdbc by date

Next:From: Bruce MomjianDate: 2004-06-17 01:36:33
Subject: Re: Nested transactions
Previous:From: Jie LiangDate: 2004-06-17 00:53:07
Subject: Re: Prepare Statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group