SEO

#1 (**permalink**) 04-09-2008, 01:00 PM

On 19 Dec 2006 08:37:01 -0800, "BigSmoke" <bigsmoke@gmail.com> wrote:

[...]

What would solve my problem is if there was a
> method to, at the end of
>> a begin/end block, I could rollback the changes made in that block
>> without having to raise an exception. Is it somehow possible to
>> explicitly rollback to one of these savepoints which are created by
>> begin/end blocks?
>
> I'm sorry for the sloppy English. Of course I meant to say "at the end
> of a begin/end block, rollback" instead of "at the end of a begin/end
> block, I could rollback". Hopefully, this didn't add in the confusion.

If you are hoping you could adopt exact Oracle behavior, i have to regret,
you have to do as you've already done. There's no such thing like 'explicit
transaction control' in plpgsql. Wouldn't it be easier to wrap your tests into
self-contained testfunctions like

SAVEPOINT A;
SELECT testcase1();
ROLLBACK TO A;
SELECT testcase2();
ROLLBACK TO A;
....

and to evaluate return codes into your application? Maybe someone knows better, but
that's the only solution that comes to my mind off-hand....

Bernd

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

#2 (**permalink**) 04-09-2008, 01:01 PM

On Dec 19, 7:03 pm, maili...@oopsware.de (Bernd Helmle) wrote:
> On 19 Dec 2006 08:37:01 -0800, "BigSmoke" <bigsm...@gmail.com> wrote:
>
> > What would solve my problem is if there was a
> > method to, at the end of a begin/end block,
> > rollback the changes made in that block
> > without having to raise an exception. Is it somehow possible to
> > explicitly rollback to one of these savepoints which are created by
> > begin/end blocks?
>
> If you are hoping you could adopt exact Oracle behavior, i have to regret,
> you have to do as you've already done. There's no such thing like 'explicit
> transaction control' in plpgsql. Wouldn't it be easier to wrap your tests into
> self-contained testfunctions like
>
> SAVEPOINT A;
> SELECT testcase1();
> ROLLBACK TO A;
> SELECT testcase2();
> ROLLBACK TO A;
> ...
>
> and to evaluate return codes into your application? Maybe someone knows better, but
> that's the only solution that comes to my mind off-hand....

Well, I'm already doing a full rollback after each test function in my
application, because I want test functions to be able to run
independently of each other. (I have multiple tests/assertions per test
function, which I why I wanted to use savepoints in these functions.)
But, I guess I _could_ make groups of tests with one test per function
where the functions in each group share some test data in the way you
describe. However, the sharing of test data would be cumbersome with
this method because I'd have to pass a lot of keys (with pointers to
the interesting rows in the test sets) to each test function.

I'll probably just stick with using tainted test data between the
individual tests in each test function. I guess I can't have
everything. ;-)

Thanks for your tips and time,

- Rowan

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: Savepoints in PL/pgSQL