Обсуждение: Do Postgres exceptions rise up the stack?

Поиск
Список
Период
Сортировка

Do Postgres exceptions rise up the stack?

От
"Postgres User"
Дата:
A basic question about raising exceptions in Postgres:

If  Function A  calls Function B

and Func B raises an exception, will the exception roll back the
transaction in Func A by default?   Or do I need to trap and re-raise
the exception in Func A?

Thanks.

Re: Do Postgres exceptions rise up the stack?

От
Wiebe Cazemier
Дата:
On Saturday 30 June 2007 23:14, Postgres User wrote:

> A basic question about raising exceptions in Postgres:
>
> If  Function A  calls Function B
>
> and Func B raises an exception, will the exception roll back the
> transaction in Func A by default?   Or do I need to trap and re-raise
> the exception in Func A?
>
> Thanks.

Any exception aborts the transaction. That's how exceptions work. If you don't
catch them, they bubble all the way to the surface. Otherwise it would be too
much like if-statement error checking.

Re: Do Postgres exceptions rise up the stack?

От
"Postgres User"
Дата:
How about this scenario:

func A()

begin
   x  =  func B();
   y  =  func C();

   z = func D();

end

Where func A, B, C, and D all update the db.  If a funciton is raised
in func D(), will all the transactions in the other children be rolled
back?
Or do I need to add code to enable this?


On 6/30/07, Wiebe Cazemier <halfgaar@gmx.net> wrote:
> On Saturday 30 June 2007 23:14, Postgres User wrote:
>
> > A basic question about raising exceptions in Postgres:
> >
> > If  Function A  calls Function B
> >
> > and Func B raises an exception, will the exception roll back the
> > transaction in Func A by default?   Or do I need to trap and re-raise
> > the exception in Func A?
> >
> > Thanks.
>
> Any exception aborts the transaction. That's how exceptions work. If you don't
> catch them, they bubble all the way to the surface. Otherwise it would be too
> much like if-statement error checking.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Re: Do Postgres exceptions rise up the stack?

От
"Postgres User"
Дата:
Where func A, B, C, and D all update the db.  If an EXCEPTION is raised
in func D(), will all the transactions in the other children be rolled
back?
Or do I need to add code to enable this?

On 6/30/07, Postgres User <postgres.developer@gmail.com> wrote:
> How about this scenario:
>
> func A()
>
> begin
>   x  =  func B();
>   y  =  func C();
>
>   z = func D();
>
> end
>
> Where func A, B, C, and D all update the db.  If a funciton is raised
> in func D(), will all the transactions in the other children be rolled
> back?
> Or do I need to add code to enable this?
>
>
> On 6/30/07, Wiebe Cazemier <halfgaar@gmx.net> wrote:
> > On Saturday 30 June 2007 23:14, Postgres User wrote:
> >
> > > A basic question about raising exceptions in Postgres:
> > >
> > > If  Function A  calls Function B
> > >
> > > and Func B raises an exception, will the exception roll back the
> > > transaction in Func A by default?   Or do I need to trap and re-raise
> > > the exception in Func A?
> > >
> > > Thanks.
> >
> > Any exception aborts the transaction. That's how exceptions work. If you don't
> > catch them, they bubble all the way to the surface. Otherwise it would be too
> > much like if-statement error checking.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
>

Re: Do Postgres exceptions rise up the stack?

От
Wiebe Cazemier
Дата:
On Saturday 30 June 2007 23:52, Postgres User wrote:

> How about this scenario:
>
> func A()
>
> begin
>    x  =  func B();
>    y  =  func C();
>
>    z = func D();
>
> end
>
> Where func A, B, C, and D all update the db.  If a funciton is raised
> in func D(), will all the transactions in the other children be rolled
> back?
> Or do I need to add code to enable this?

(Noted correction in other reply).

It will be rolled back. When you don't begin a transaction explicitly,
postgresql creates one implicitely when you execute a function. So, calling a
function will always be atomic.