Re: Vote totals for SET in aborted transaction

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
>

In response to

Browse pgsql-hackers by date

  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