failed executeSql() causes "ERROR: SPI_finish() failed" about plv8 HOT 8 CLOSED

The error message will be
  ERROR:  current transaction is aborted, commands ignored until end of transaction block
on Revision: 5049be9218a9.

However, you cannot continue transactions on SQL errors although the error can 
be caught.
There is no relationship between "try" in JavaScript and SAVEPOINT in postgres.
We don't make a SAVEPOINT at "try" block.

We need to decide how to handle transaction-level errors in JavaScript.
I have 3 ideas about the issue:

  A. Make SQL errors uncaught-able because users cannot ignore the error. 
  B. Support sub-transactions via making SAVEPOINTs for every "try" block. 
  C. Support sub-transactions via some special functions, like:
      prepareTransaction(name);
      try { ... }
      catch (e) { rollbackToSavePoint(name); }

Comments and/or any better ideas?

If we have no way to handle transaction in current implementation, I'd think 
it's a good chance, so B. But what was drawback of B compared with C? It seems 
to me that auto-transaction has kind of overhead.

It seems plpython makes subtransactions for each SPI execution. I think it's 
better than B.

We might have an option for SPI exectuion something like ON_ERROR_ROLLBACK in 
psql.

I don't like to introduce any options to users here.  Do you mean introducing a 
GUC to let users to choose the behavior??

I'm going to implement subtransaction() rather than try-catch.

subtransaction(function(){
  executeSql(...)
})

BTW, I'm inclined to define a global object, plv8, to separate builtin function 
namespace.  Thoughts?

Pushed 485c509a9f3e5f9fd7425bc72970002618cbe217

Now executeSql runs the statement in a sub-transaction always.  If the 
statement fails, the sub-transaction is aborted and exception is thrown.  
Subsequent process is allowed to run another SQL instead of SPI_finish() 
failure or top-transaction abortion message.

Also like I said above, I added subtransaction function to let users make 
explicit sub-transaction block.  Since executeSql() now runs in its own 
sub-transaction, users need explicit sub-transaction block when needed.