Re: Information on savepoint requirement within transctions - Mailing list pgsql-general

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.