Gavin Sherry wrote:
> Its not that there's a rationale behind it. Rather, the existing error
>
>handling code *has* to abort the current transaction because an error has
>taken place. In a multi statement transaction block (ie, BEGIN; ...; ...;
>... COMMIT;) each statement piggy backs on onto the whole transaction.
>Because we're aborted one query, we've aborted them all.
>
>With nested transactions, every query within a transaction block could be
>run within its own (sub)transaction. The backend could be jigged so
>that if parse errors occur, we abort the second level transaction and roll
>back to the start point at the moment before the error generating
>statement took place. This keeps the rest of the queries executed in the
>transaction block in place
>
>
Who is currently working on this [nested transactions] and what
specifically needs to be done at this point?
This is a major bug which greatly diminishes the confidence of my
co-workers in postgresql. I don't
don't have a wealth of knowledge about RDBMS implementations. How can I
best contribute to
solve this problem?
Andrej
