From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: plpgsql's EXIT versus block and loop nesting |
Date: | 2009-05-01 13:03:26 |
Message-ID: | 49FAF31E.1040408@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Whilst fooling with some plpgsql code translated from Oracle, I found
> out that we interpret this construct differently than they do:
>
> while true loop
> begin
> -- some code that might throw unique_violation
>
> exit;
> exception when unique_violation then
> -- take a recovery action (then go 'round the loop again)
> end;
> end loop;
>
> The code author obviously expects that the EXIT will exit the WHILE
> loop, so I assume that's what Oracle does with it. What plpgsql is
> doing is matching the EXIT to the BEGIN block, which means this is
> an infinite loop.
>
> Aside from the question of Oracle compatibility, ISTM this behavior
> is at variance with what our manual says about EXIT:
>
> If no label is given, the innermost loop is terminated and the
> statement following END LOOP is executed next.
>
> I'm not sure we should change this in the back branches, but I propose
> that for 8.4, we fix it so that EXIT will only match to a begin-block
> if the block has a label and it matches the EXIT's. Unlabeled EXITs
> should match to the innermost loop, like the manual says. (This looks
> to be about a one-line code change.)
>
> Comments?
>
>
>
It's certainly a bug and should be fixed. Given what the docs say I'd
say there's a good case for backpatching it. OTOH, nobody has complained
about it all these years.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-05-01 13:49:28 | Re: idea: global temp tables |
Previous Message | Andrew Dunstan | 2009-05-01 12:58:08 | Re: Perl coding style in postgresql |