Tracebacks in forms are mostly caused by postgresql being more picky with SQL syntax: It doesn't allow non-numeric IDs (which mysql and sqlite are happy with) and has many other constraints (e.g. syntax errors in Date properties) that cause a postgres-specific Exception (the toplevel Exception is a psycopg2.errors.DataError).
We now catch this exception and re-raise it as a hyperdb.HyperdbValueError. There is a complication with this: When postgres throws an error the current transaction is aborted. We need to roll back to the point before the erroneous SQL statement. We cannot roll back the whole transaction as this would cause malfunctions for longer transactions. The solution is to add a savepoint before statements that can cause a postgres DataError.

There are some cases where errors in forms throw an IndexError which is not caught by the framework (a ValueError *is* caught). These lead to tracebacks for *all* backends.

Finally in field methods of some HTMLProperty classes we need to call client.add_error_message instead of raising the error. This will show the error message to the user and not cause a traceback.