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