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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to