Re: Nested transactions

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@postgresql.org