Allow nested transactions

Hello all,

As you know, PostgreSQL handles in a restricted way a transaction, falling in
*ABORT STATE*, when a statement which yields error is entered. Not only the
transaction isn't allowed to continue processing statements, until a finishing
statement is entered, but also the whole transaction is ROLLedBACK, regardless
of which statement finished the transaction (ABORT, ROLLBACK, COMMIT, END).

I'm needing as water the ability of PostgreSQL to continue working normally
after an error within a transaction, and not to fall in *ABORT STATE*. Many of
you already read my previous messages about this topic, and maybe my insistence
is becoming upsetting. I apologize.

I'm willing to do it myself. But my lack of knowledge about many required
topics, leaves my chances low. So I'm following alternative paths, as to try to
persuade others of the importance of this issue.

In the TODO list, we can read:

> EXOTIC FEATURES
> 
> * Add sql3 recursive unions
> * Add the concept of dataspaces
> * Add replication of distributed databases
> * Allow queries across multiple databases
> * Allow nested transactions (Vadim)

From this, I understand that:

1) The development group found that the behaviour change proposed above, will be
achieved, by encapsulating offending statements within inner transactions, so
that outer ones remain OK, and can follow to process statements, until COMMIT;
not by changing such behaviour directly. I haven't found in the TODO list, other
related items.

2) The priority assigned to this issue is sort of low, since it's below EXOTIC
FEATURES, and is in the last in the list.

Making transactions nestable, will surely become a great feature, compared to
competitor databases. And Vadim seems to be the only one able to cope with it,
and he has to do lots of things before this one.

I wonder if by focusing narrowerly at the desired behaviour change (not to fall
in ABORT STATE), we could achieve sooner one of the two goals.

I'm using JDBC to communicate with the backend. If nesting transactions were the
solution, I wonder if by enclosing <*automatically within the driver*> each
statement inside a nested transaction, would appear to the frontend app, as if
PostgreSQL handled offending statements within transactions in a smooth way. Of
course this wouldn't be a general solution, so, maybe creating a "SET
ENCLOSE_EVERY_POSSIBLE_OFFENDING_STATEMENT [ON|OFF]" backend statement, we could
achieve the desired behaviour change.

As you can see, I have some ideas, I have needs, I'm poorly trying to solve the
problem, and I want all of you to discuss about this. I have found that my
worrying about this, is shared by some PostgreSQL users, i.e., when trying to
insert a record, in case it didn't exist previously, and update it, in case it
exists, problem which has been discussed a lot lately, in the GENERAL list.

Many of you have already helped me in a way or another in this issue, including
but not limited to Peter Eisentrout, and Ed Loehr. Special thanks to you.

What do you think?

Best Regards,
Haroldo Senger.