From: | "John Ingram" <jingram(at)ncinter(dot)net> |
---|---|
To: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vote totals for SET in aborted transaction |
Date: | 2002-04-30 02:55:56 |
Message-ID: | 009601c1eff2$8d9411e0$b642a6d0@oemcomputer |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Original Message -----
From: "Marc G. Fournier" <scrappy(at)hub(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hannu Krosing" <hannu(at)tm(dot)ee>; "Scott Marlowe" <scott(dot)marlowe(at)ihs(dot)com>;
"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Sent: Monday, April 29, 2002 2:10 PM
Subject: Re: [HACKERS] Vote totals for SET in aborted transaction
LOCAL <NESTED TRANSACTION NAME> SET .... ?
>>
>
> What happens inside of a nested transaction, assuming we do have those
> evenually ... ?
>
> On Mon, 29 Apr 2002, Tom Lane wrote:
>
> > Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > > 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.
> >
> > This makes my head hurt. If I do
> >
> > SET foo TO bar;
> > begin;
> > SET SET TO GLOBAL;
> > SET foo TO baz;
> > SET SET TO LOCAL TO TRANSACTION;
> > end;
> >
> > (assume no errors) what is the post-transaction state of foo?
> >
> > What about this case?
> >
> > SET foo TO bar;
> > begin;
> > SET SET TO GLOBAL;
> > SET foo TO baz;
> > SET SET TO LOCAL TO TRANSACTION;
> > SET foo TO quux;
> > end;
> >
> > Of course this last case also exists with my idea of a LOCAL SET
> > command,
> >
> > SET foo TO bar;
> > begin;
> > SET foo TO baz;
> > LOCAL SET foo TO quux;
> > -- presumably SHOW foo will show quux here
> > end;
> > -- does SHOW foo now show bar, or baz?
> >
> > Arguably you'd need to keep track of up to three values of a SET
> > variable to make this work --- the permanent (pre-transaction) value,
> > to roll back to if error; the SET value, which will become permanent
> > if we commit; and the LOCAL SET value, which may mask the pending
> > permanent value. This seems needlessly complex though. Could we get
> > away with treating the above case as an error?
> >
> > In any case I find a LOCAL SET command more reasonable than making
> > SET's effects depend on the value of a SETtable setting. There is
> > circular logic there. If I do
> >
> > begin;
> > SET SET TO LOCAL TO TRANSACTION;
> > end;
> >
> > what is the post-transaction behavior of SET? And if you say LOCAL,
> > how do you justify it? Why wouldn't the effects of this SET be local?
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-04-30 03:01:34 | Re: Civility of core/hackers group |
Previous Message | Bruce Momjian | 2002-04-30 02:54:07 | Re: Civility of core/hackers group |