Skip site navigation (1) Skip section navigation (2)

Re: Vote on SET in aborted transaction

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Thomas Lockhart <lockhart(at)fourpalms(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote on SET in aborted transaction
Date: 2002-04-25 00:52:31
Message-ID: 200204250052.g3P0qVD06246@saturn.janwieck.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Hiroshi Inoue wrote:
> Tom Lane wrote:
> >
>
> > Right offhand, I am not seeing anything here for which there's a
> > compelling case not to roll it back on error.
> >
> > In fact, I have yet to hear *any* plausible example of a variable
> > that we would really seriously want not to roll back on error.
>
> Honetsly I don't understand what kind of example you
> expect. How about the following ?
>
> [The curren schema is schema1]
>
>         begin;
>         create schema foo;
>         set search_path = foo;
>         create table t1 (....);
>         .
>    [error occurs]
>         rollback;
>         insert into t1 select * from schema1.t1;
>
> Should the search_path be put back in this case ?
> As I mentioned already many times, it doesn't seem
> *should be* kind of thing.

    Sure  should  it!  You  gave  an example for the need to roll
    back, because otherwise you would  end  up  with  an  invalid
    search path "foo".

    I  still believe that rolling back is the only right thing to
    do. What if your application  doesn't  even  know  that  some
    changes happened? Have a trigger that set's seqscan off, does
    some stuff and intends to reset it later again. Now it elog's
    out  before,  so your application will have to live with this
    mis-setting on this pooled DB connection until  the  end?   I
    don't think so!


Jan


--

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



In response to

Responses

pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2002-04-25 01:06:04
Subject: Re: Vote on SET in aborted transaction
Previous:From: Bruce MomjianDate: 2002-04-25 00:39:28
Subject: Vote totals for SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group