Re: Vote totals for SET in aborted transaction

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <janwieck@yahoo.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-04-25T02:00:41Z
Lists: pgsql-hackers
Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > > 
> > > Hiroshi Inoue wrote:
> > > > Bruce Momjian wrote:
> > > > >
> > > > > > > >
> > > > > > > > I voted not only ? but also 2 and 3.
> > > > > > > > And haven't I asked twice or so if it's a vote ?
> > > > > > >
> > > > > > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > > > > > decide what to do.
> > > > > > >
> > > > > > > Hiroshi, you can't vote for 2, 3, and ?.
> > > > > >
> > > > > > Why ?
> > > > > > I don't think the items are exclusive.
> > > > >
> > > > > Well, 2 says roll back only after transaction aborts,
> > > >
> > > > Sorry for my poor understanding.
> > > > Isn't it 1 ?
> > > 
> > > OK, original email attached. 1 rolls back all SETs in an aborted
> > > transaction. 
> > 
> > > 2 ignores SETs after transaction aborts, but  SETs before
> > > the transaction aborted are honored.
> > 
> > Must I understand this from your previous posting
> > (2 says roll back only after transaction aborts,)
> > or original posting ? What I understood was 2 only
> > says that SET fails between a failure and the
> > subsequenct ROLLBACK call.
> 
> Yes, 2 says that SET fails between failure query and COMMIT/ROLLBACK
> call, which is current behavior.

    What about a SET variable that controls the behaviour of
    SET variables :-)


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #