Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group