Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers

From John Ingram
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 009601c1eff2$8d9411e0$b642a6d0@oemcomputer
Whole thread Raw
In response to Re: Vote totals for SET in aborted transaction  ("Marc G. Fournier" <scrappy@hub.org>)
List pgsql-hackers
----- Original Message -----
From: "Marc G. Fournier" <scrappy@hub.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Hannu Krosing" <hannu@tm.ee>; "Scott Marlowe" <scott.marlowe@ihs.com>;
"PostgreSQL-development" <pgsql-hackers@postgresql.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@tm.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@postgresql.org)
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Civility of core/hackers group
Next
From: mlw
Date:
Subject: Re: Civility of core/hackers group