On Tue, 2004-09-14 at 11:56, Peter Eisentraut wrote:
> Michael Paesold wrote:
> > I though the postgres behaviour of rolling back the whole transaction
> > was standard?
>
> No.
>
> > If that is not the case, I don't understand why core
> > seems to be against a mode (GUC), where an implicit savepoint is
> > generated before each statement so that "rollback of the last
> > statement" would be possible.
>
> Because it's dangerous in noninteractive mode. When you send a
> transaction to the server, you don't want some statements be left out.
But it does not mean the server will commit the transaction for you...
it will throw an exception on the failed query, and it's up to you to
continue the transaction, commit it right away, or to roll it back. Old
code will probably just work fine if it will roll back on any received
error, which it had to do anyway even with the current behavior.
So it is just giving more choice to the developer instead of deciding
for him that the transaction is failed... and yes, there are valid
scenarios where it is quicker to execute a query and based on the fact
that it fails or not do different things, without the need of redoing
the whole transaction executed before.
It's another story that this feature should not be turned on by default
if it has some performance overhead (which I suppose it has, as setting
a savepoint is probably not free).
Just my 2c,
Csaba.