Greg Stark <gsstark@mit.edu> writes:
> But why does the database enforce that every syntax error *requires* a
> transaction roll back?
PG enforces that every error requires a transaction abort. Period, full
stop. Picking and choosing which errors might not really require a
rollback involves a level of detailed code-behavior analysis (and
consequent fragility in the face of changes) that no one has wanted to
undertake.
As an example: "SELECT * FROM foo" where foo doesn't exist will result
in a 'not found' error reported from somewhere in the catalog lookup
code. Fine, we probably wouldn't need a transaction abort to clean up
after that. But there are a ton of error cases right next door in that
same code that we'd better do an abort to clean up after --- deadlocks,
corrupted data structures, who knows what. Even 'not found' is
problematic if the elog-induced longjmp occurs at a point where we're
holding some locks or other resources that need to be released.
What it comes down to is that a lot of code in the backend assumes that
transaction abort can be relied on to do any post-elog cleanup needed,
such as releasing locks or reclaiming leaked memory. I don't think we
can afford to give up that assumption; the costs in code complexity and
instability would be horrific. What we have to do is generalize the
abort cleanup code so it can handle partial rollbacks as well as
complete ones. Thus "nested transactions" is really a shorthand for
this problem of post-error cleanup.
> And nested transactions are a red herring.
You seem to think this is being driven by user-interface issues. It's
an implementation necessity.
regards, tom lane
