[Ur] Exceptions handling

[Karn Kallio]

> Vladimir Shabanov wrote:
> > So savepoint will be introduced only where it really needed (dml with
> > user error handling)? I think that this is the best solution.
> 
> Yes, that's what I meant.
> 
> > BTW it can be useful to have function for cancelling (and maybe
> > restarting) transaction as a part of error handling.
> 
> In Ur/Web, transactions are used for all state, not just the database.
> I would want to have a reasonable integration of transaction restart
> with all kinds of state, which can include arbitrary protocols thanks to
> C FFI libraries.  That would complicate the FFI, so I'll leave this out
> for now.  If a compelling use case comes up, let me know.

In PostgreSQL, use of the Serializable transaction isolation level will give 
failures whenever for example a transaction selects a set of rows and another 
concurrent transaction modifies some before the query finishes.

These serialization failure errors generally need the application to cancel 
and retry the transaction.

So I suppose with PostgreSQL, a use case could be any situation where 
Serializable isolation levels are called for.

Transactions that include a mixture of complicated selects and updates will 
probably need the Serializable isolation level.  An example could be some sort 
of reporting application where "presentation" tables are filled with results 
computed from "input" tables via multiple steps with several layers of tables 
holding intermediate results.  If many users are concurrently adding data to 
the input tables and viewing the presentation tables Serializable would 
probably be necessary.  Whenever two users input data that resulted in 
overlapping changes in an intermediate result table cancel/retry would have to 
be done.

Reference: http://www.postgresql.org/docs/8.4/static/transaction-iso.html 
Section 13.2.2