On 26.01.2018 17:11, David G. Johnston wrote:
> The convention for these lists is to inline or bottom-post. Top-posting
> is discouraged.
Okay, I'll keep it in mind.
> Here's my take, the docs support this but maybe take some interpretation...
>
> A SAVEPOINT begins what is effectively a sub-transaction without ending
> the main transaction. If that sub-transaction fails you can throw it away
> (ROLLBACK TO) and pretend that it didn't happen: you are dropped back to
> the point where the savepoint was issued and the main transaction
> re-engaged.
>
> Its kinda like a try/catch block:
>
> BEGIN:
>
> do_stuff
>
> SAVEPOINT try { lets_fail; this_works; } catch { ROLLBACK TO }
>
> do_more_stuff
>
> COMMIT;
>
> As long as both do_stuff and do_more_stuff succeed when you commit the
> things that they did will persist.
>
> The stuff in lets_fail AND this_works, however, will be discarded because
> of the lets_fail failing and this_works belonging to the same
> sub-transaction.
>
> If do_more_stuff depends on lets_fail or this_works succeeding then
> do_more_stuff will fail and will cause do_stuff to rollback as well.
Thanks for the detailed explanation, that helps a lot. However, I'm still
looking for "official" documentation on their *requirement* in combination with
failing statements. Documentation, bug report, mailing list discussions,
something like that. In particular I'm interested in the questions:
* Why are they required in combination with failing statements (when every
other database does an "automatic savepoint and rollback" for a failed statement)?
* When was that behavior chosen? Was it always like that? Was it adopted later?
* What is the design decision behind it?
There is a lot of information on what savepoints are and how they work (and also
thanks to you I'm now fairly certain I have good grasp on them), but I fail to
locate documentation on these questions.
