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