Thomas Lockhart <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
