The `test_disable_referential_integrity_as_.*_with_invalidated_transaction` tests verify that if the passed block invalidates the current transaction, our code successfully rolls back to a savepoint and is able to re-enable referential integrity.

The `test_disable_referential_integrity_as_nonsuperuser_fails_.*` tests do serve more as documentation of the current behavior, but I'd prefer to leave them there until we fix things.  The long-term goal is to make it work as nonsuperuser for scenarios in which the foreign key is defined as deferrable, as discussed in way too much length in https://groups.google.com/forum/?fromgroups#!topic/rubyonrails-core/n82I-OXYyD4.  The conclusion I came to in that post is:

> My suggestions are as follows:
> * If the user has SUPERUSER, disable all triggers.  This ensures we can
>   disable referential integrity even if the constraints weren't declared
>   with DEFERRABLE, so long as the user has SUPERUSER.
> * If the user doesn't have SUPERUSER, disable all user triggers and then
>   use SET CONSTRAINTS ALL DEFERRED.
>   * If the call was made from within a transaction, there is no need to
>     create a nested transaction.
>   * If the call was not made from within a transaction, create one
>     before calling SET CONSTRAINTS ALL DEFERRED and yield to the block
>     from within that transaction.

Once we do that, the test suite can be modified to validate that the above behavior works.