Karel Zak <[EMAIL PROTECTED]> writes:
> Is there some problem implement "SET ... ON ROLLBACK UNSET" ?
Yes. See my previous example concerning search_path: that variable
MUST be rolled back at transaction abort, else we risk its value being
invalid. We cannot offer the user a choice.
So far I have not seen one single example against SET rollback that
I thought was at all compelling. In all cases you can simply issue
the SET in a separate transaction if you want to be sure that its
effects persist. And there seems to be no consideration of the
possibility that applications might find SET rollback to be useful.
ISTM that the example with JDBC and query_timeout generalizes to other
parameters that you might want to set on a per-statement basis, such
as enable_seqscan or transform_null_equals. Consider
BEGIN;
SET enable_seqscan = false;
some-queries-that-might-fail;
SET enable_seqscan = true;
END;
This does not work as intended if the initial SET doesn't roll back
upon transaction failure. Yeah, you can restructure it to
SET enable_seqscan = false;
BEGIN;
some-queries-that-might-fail;
END;
SET enable_seqscan = true;
but what was that argument about some apps/drivers finding it
inconvenient to issue commands outside a transaction block?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
