RE: PL/SQL Interpreter oddity - bug or "expected"?

From: Mark W. Farnham <>
Date: Mon, 19 Mar 2018 16:57:41 -0400
Message-ID: <001b01d3bfc4$fabbc020$f0334060$>

Stefan, please file the business case that allowing unmatched block labels are error prone for human readers.  

Then, regardless of whether it is handled as and “enhancement request” or as a “deficiency removal” it will have a chance for action.  

I would offer the slight enhancement to the enhancement that this be handled as a warning by default, lest we cause apparently correctly (or at least unnoticed) running code that has textual deficiencies to continue as they are.  

I *suspect* the modern culture of unit testing by getting through the compiler has created a sufficient mass of such code to justify being wary in unleashing the enhancement.  

Thanks Bryn. Thanks Toon.  


From: [] On Behalf Of Michael D O'Shea/Woodward Informatics Ltd Sent: Monday, March 19, 2018 4:55 AM
Cc: Toon Koppelaars; oracle-l-freelists
Subject: Aw: PL/SQL Interpreter oddity - bug or "expected"?    

> Am 19.03.2018 um 07:57 schrieb Stefan Knecht <>:


> So to summarize, I still feel that the behavior isn't what

> I'd expect. Regardless of what "loop" is underneath the covers,

> it has a special meaning, and that meaning is entirely obliterated

> by the compiler treating it as a mere label.

The take home message from this whole thread is not null block usage or how contributors used terms such as label, keyword, reserved word, or other semantic terms, but that PL/SQL language grammar & syntax allow for the confusion demonstrated in the OP’s code. This is a deficiency and we should not get carried away with semantic terms.  

Here, as also included in this thread <,-keywords,-and-the-ends-of-labeled-blocks> Bryn Llewellyn writes  

> Please check out this enhancement request. I filed it on 31-Mar-2008.


> ER 6931048 - Implement new warning when block label doesn't match “end ... ;”


If one were pedantic, one would argue this is not an „enhancement request“ (as written) but a „deficiency removal“. You see, arguing over semantic terms gets us nowhere. The bottom line is that PL/SQL language syntax and grammar allows for this coding man-trap and as such it is currently broken. Furthermore, according to Bryn’s „enhancement request“, it has been broken for at least a decade, so obviously not broken enough to warrant being fixed.  

My twopence.  


Received on Mon Mar 19 2018 - 21:57:41 CET

Original text of this message