From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:41:17 |
Message-ID: | 1020098478.27494.23.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2002-04-29 at 17:30, Tom Lane wrote:
> Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com> writes:
> > I've been thinking this over and over, and it seems to me, that the way
> > SETS in transactions SHOULD work is that they are all rolled back, period,
> > whether the transaction successfully completes OR NOT.
>
> This would make it impossible for SET to have any persistent effect
> at all. (Every SQL command is inside a transaction --- an
> implicitly-established one if necesary, but there is one.)
>
> It might well be useful to have some kind of LOCAL SET command that
> behaves the way you describe (effects good only for current transaction
> block), but I don't think it follows that that should be the only
> behavior available.
>
> What would you expect if LOCAL SET were followed by SET on the same
> variable in the same transaction? Presumably the LOCAL SET would then
> be nullified; or is this an error condition?
Perhaps we could do
SET SET TO LOCAL TO TRANSACTION;
Which would affect itself and all subsequent SET commands up to
SET SET TO GLOBAL;
or end of transaction.
-------------
SET SET TO GLOBAL
could also be written as
SET SET TO NOT LOCAL TO TRANSACTION;
to comply with genral verbosity of SQL ;)
----------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | tony | 2002-04-29 16:42:13 | Re: pid gets overwritten in OSX |
Previous Message | Marc G. Fournier | 2002-04-29 16:38:44 | Re: Vote totals for SET in aborted transaction |