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

From Marc G. Fournier
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 20020425094929.V2368-100000@mail1.hub.org
Whole thread Raw
In response to Vote totals for SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Vote totals for SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Just curious here, but has anyone taken the time to see how others are
doing this?  For instance, if we go with 1, are going against how everyone
else handles it?  IMHO, its not a popularity contest ...

Personally, I do agree with #1, but I'm curious as to how those coming
from other DBMS are going to have problems if this isn't what they are
expecting ...


On Wed, 24 Apr 2002, Bruce Momjian wrote:

>
> OK, the votes are in:
>
>     #1
>     Lamar Owen
>     Jan Wieck
>     Tom Lane
>     Bruce Momjian
>     Joe Conway
>     Curt Sampson
>     Michael Loftis
>     Vince Vielhaber
>     Sander Steffann
>
>     #2
>     Bradley McLean
>
>
>
>     #3
>
>     #?
>     Thomas Lockhart
>     Hiroshi Inoue
>
> Looks like #1 is the clear winner.
>
> ---------------------------------------------------------------------------
>
> Bruce Momjian wrote:
> > OK, would people please vote on how to handle SET in an aborted
> > transaction?  This vote will allow us to resolve the issue and move
> > forward if needed.
> >
> > In the case of:
> >
> >     SET x=1;
> >     BEGIN;
> >     SET x=2;
> >     query_that_aborts_transaction;
> >     SET x=3;
> >     COMMIT;
> >
> > at the end, should 'x' equal:
> >
> >     1 - All SETs are rolled back in aborted transaction
> >     2 - SETs are ignored after transaction abort
> >     3 - All SETs are honored in aborted transaction
> >     ? - Have SETs vary in behavior depending on variable
> >
> > Our current behavior is 2.
> >
> > Please vote and I will tally the results.
> >
> > --
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 853-3000
> >   +  If your life is a hard drive,     |  830 Blythe Avenue
> >   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>



pgsql-hackers by date:

Previous
From: Lee Kindness
Date:
Subject: ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Next
From: "Sander Steffann"
Date:
Subject: Re: Vote totals for SET in aborted transaction