Re: Vote totals for SET in aborted transaction

> 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.

This is certainly not in the same category. And I'm sure you can see
upon rereading my post that I made no claim that this is a trivial
point. Though it certainly can be fun to pick and choose words to make
them into whatever we want them to say, I *meant* that focusing on
trivial details in semantics of postings was diverting the discussion
from the underlying technical issues which I'm sure you see. But here we
go again... ;)

> 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.

Ah, good, a technical issue :) And you are right, this would need to be
addressed. But that certainly is not a fundamental problem.

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

Right. And there was no suggestion that there be so; the original
proposal used "BEGIN/END blocks" to differentiate the usage. Think about
SET SESSION... as a possible syntax to completely decouple the behaviors
if an explicit notation is desired.

We currently have a specific behavior of SET which does not quite match
other databases. We are considering changing the behavior *farther away*
from conventional behavior. I have no problem with that. But if we are
changing it, look farther ahead to see where we want to end up. We now
have schemas to help encapsulate information. We could start attaching
properties to schemas to help encapsulate behaviors. We may someday have
nested transactions, which encapsulate transaction behaviors at a finer
grain than we have now. Let's choose approaches and behaviors which
could support these things in the future, as well as supporting our
current feature set.

- Thomas