Re: Vote totals for SET in aborted transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-29 16:06:21
Message-ID: 24247.1020096381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)fourpalms(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-29 16:20:07 Re: Vote totals for SET in aborted transaction
Previous Message Tom Lane 2002-04-29 15:53:29 Re: Vote totals for SET in aborted transaction