Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 24247.1020096381@sss.pgh.pa.us
Whole thread Raw
In response to Re: Vote totals for SET in aborted transaction  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.org> writes:
> Let's not let trivial english semantics divert the discussion please.

It's hardly a trivial point, seeing that transactions are such a
fundamental aspect of the system.  The statements that we have now that
depend on being-in-a-transaction-block-or-not (eg, VACUUM) are ugly
kluges IMHO.

Let me give you another reason why having only local SET would be a bad
idea: how are you going to issue a SET with any persistent effect when
working through an interface like JDBC that wraps every command you give
in a BEGIN/END block?  We have also talked about modifying the backend's
behavior to act like BEGIN is issued implicitly as soon as you execute
any command, so that explicit COMMIT is always needed (at least some
people think this is necessary for SQL spec compliance).  Either one of
these are going to pose severe problems for the user-friendliness of SET
if it only comes in a local flavor.

I can certainly think of uses for a local-effects flavor of SET.
But I don't want that to be the only flavor.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Tom Lane
Date:
Subject: Re: Vote totals for SET in aborted transaction