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 [EMAIL PROTECTED]


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to