Re: plpgsql's EXIT versus block and loop nesting - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: plpgsql's EXIT versus block and loop nesting
Date
Msg-id 49FAF31E.1040408@dunslane.net
Whole thread Raw
In response to plpgsql's EXIT versus block and loop nesting  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Perl coding style in postgresql
Next
From: Tom Lane
Date:
Subject: Re: User documentation on signal handling