No thank you. One of the things I love about SQL is that it doesn't throw. Adding another unit test or two to pgTAP would be my preference over assertions firing unexpectedly.<p>The relations and constraints should establish a contract between application and data. If you are making assumptions on the structure of the data, that goes in a unit test to be run when testing DB schema migrations. Not writing good tests? Well that's a root problem that needs to be dealt with. If you can't expect proper unit tests of your DB structure, why would you expect proper assertion usage to be better?<p>Then there's the issue of app code. Far too many apps have two states: all good and "something bad happened" where bad is one of "database/network path went down", "database schema updated", or "bad data". Most software isn't written to determine what kind of error, only "something bad happened with the query". Adding failed assertions to the "something bad happened" list doesn't seem to change the equation much to me.<p>If someone changed code to use a multiset instead of a set, would you expect that to be caught by an assertion at runtime or with a test suite during development and integration?