After exploring the `(create|rollback_to|release)_savepoint` methods, I'm not entirely comfortable using them.  Those methods get called by the code for [`SavepointTransaction`](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb#L181-L200), and based on what I'm seeing in those methods and [`current_savepoint_name`](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L413-L415), I get the feeling that if I start using those methods I'll be messing with the savepoints used by the enclosing transaction if the call to `disable_referential_integrity` is made from within a nested transaction.  That would prevent the enclosing transaction from rolling back or committing, since I'd wipe out the savepoint it is using!

But it turns out that all of the above is not, technically, the case.  First off, the savepoint created for a transaction gets created during the initialization for the `SavepointTransaction`, which is before it gets returned and assigned to `@transaction` for the connection.  So if I have a `SavepointTransaction` for which `#number` returns 2, the savepoint for it is `active_record_1`.  Which explains all that weird [`finishing?` and `number` code](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb#L84-L98).

So we wouldn't stomp on the savepoints used by the enclosing transaction, but we could collide with the enclosed transaction if there is one created inside the yield block.  Except that we're very careful to release our savepoints before yielding, so we'll be fine.  So long as the approach above for naming the savepoints doesn't change.  Except that there's another caveat!  PostgreSQL doesn't entirely conform to the SQL Standard.  I found the following at http://www.postgresql.org/docs/9.2/static/sql-savepoint.html:

> SQL requires a savepoint to be destroyed automatically when another savepoint with the same name is established. In PostgreSQL, the old savepoint is kept, though only the more recent one will be used when rolling back or releasing. (Releasing the newer savepoint with RELEASE SAVEPOINT will cause the older one to again become accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming.

So even if the `create_savepoint` created a savepoint with the same name as the one used by the enclosing nested transaction, we would still be safe as long as we released that savepoint before exiting our code, because then PostgreSQL would make the previous savepoint with the same name visible once again.

I guess all I'm left with is this.  I had to do all this research through the code base and PostgreSQL's behavior to figure out how things actually behaved to realize that there are at least two levels of protection against all of things that worry me.  But that may not be immediately evident to anyone else looking at the code.  Right now, the only place in ActiveRecord that uses the `(create|rollback_to|release)_savepoint` methods is the `SavepointTransaction` code, and it seems to me from looking at the methods that they were created with that specific use in mind and no others (otherwise there would be ways to create savepoints with custom names or to use random names and return a savepoint object that the caller must hang on to for rolling back or releasing, or some other mechanism for keeping the savepoint names from colliding).  Personally, I would have placed the responsibility for naming the savepoints in the `SavepointTransaction` code and put the responsibility for creating/rolling back/releasing them (but not naming them) in the Adapter code.  That would makes it easy for others to reuse the code without having naming collisions.

Side note: It appears that the savepoint created by a nested transaction persists if the transaction is rolled back.  It doesn't persist if the transaction succeeds.  The following doesn't throw an error:
```
      @connection.transaction { raise ActiveRecord::Rollback }
      @connection.release_savepoint
```
If you use an empty block for the transaction, it does.  Successful transactions release their savepoints, whereas rolled back transactions roll back to theirs but leave them behind.  Maybe this is a good thing, but it does strike me as a tad unexpected.


For whatever reason, I can't seem to find your comment on reusing the value of `in_transaction` in GitHub itself, but the above exploration also clued me into `open_transactions`, which seems to be a reliable method for determining if we are in a transaction (at least within a transaction known to ActiveRecord).  I'm modifying the code to use `open_transactions > 0` as a test for all of the savepoint code, including the initial creation of the savepoint.  The disadvantage to this approach is that the code will assume there's no transaction if the user manually creates a transaction by executing raw SQL (instead of by using the ActiveRecord support).  Am I safe in assuming that users manually creating transactions are asking for any trouble they get?