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

From: Sayan Malakshinov <xt.and.r_at_gmail.com>
Date: Sat, 17 Mar 2018 18:29:22 +0300
Message-ID: <CAOVevU5eWJg-WKKhjx_NZjqCVgRG+Q1NVMqoEgHDr8P7COSa4g_at_mail.gmail.com>



Hi Stefan,

Matthias absolutely right. For example, the following examples are valid and work fine because LOOP is not reserved word:

declare
  function loop return int as
  begin

     return 1;
  end loop;
begin

   dbms_output.put_line(loop);
end;
/
<<LOOP>>
declare
  x number:=1;
begin

   <<LOC>>
   declare x number:=2;
   begin

      dbms_output.put_line('LOOP: '||LOOP.X);
      dbms_output.put_line('LOC:  '||LOC.X);
   end LOC;
end LOOP;
/
You can notice the difference if you replace LOOP with IF.

On Sat, Mar 17, 2018 at 6:16 PM, Stefan Knecht <knecht.stefan_at_gmail.com> wrote:

> I don't think it's all that relevant whether it's a reserved word or not.
> It's a part of the PL/SQL language (and a key part thereof).
>
> The main problem I have with it is that code can compile if you're missing
> an opening loop statement. That can result in unexpected behavior when that
> code is then executed.
>
> IMHO that should not be possible.
>
>
>
> On Sat, Mar 17, 2018 at 9:39 PM, <rogel_at_web.de> wrote:
>
>> Hi Stefan,
>>
>> well, at least *IF* is in *V$RESERVED_WORDS* ( in contrast to *LOOP*)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *sokrates_at_12.1 > call print_table(q'| 2 select * from v$reserved_words
>> where upper(keyword) in ('LOOP', 'IF') 3 |') 4 /
>> KEYWORD : IF LENGTH : 2
>> RESERVED : N RES_TYPE : N
>> RES_ATTR : N RES_SEMI : N
>> DUPLICATE : N CON_ID : 0
>> ----------------- 1 Zeile selektiert.*
>>
>>
>> Matthias
>>
>> *Gesendet:* Samstag, 17. März 2018 um 11:29 Uhr
>> *Von:* "Stefan Knecht" <knecht.stefan_at_gmail.com>
>> *An:* "Matthew Parker" <dimensional.dba_at_comcast.net>
>> *Cc:* oracle-l-freelists <oracle-l_at_freelists.org>
>> *Betreff:* Re: PL/SQL Interpreter oddity - bug or "expected"?
>> Yeah I don't think it's about reserved words per se - "IF" isn't a
>> reserved word either, but is correctly handled (correct IMHO).
>>
>>
>>
>> On Sat, Mar 17, 2018 at 3:44 PM, Matthew Parker <
>> dimensional.dba_at_comcast.net> wrote:
>>>
>>> From a Oracle SQL Reserved Word prospective you might think so but when
>>> you go to the documentation on Reserved Words, “loop” is not listed.
>>>
>>>
>>>
>>> https://docs.oracle.com/database/121/SQLRF/ap_keywd001.htm#SQLRF55621
>>>
>>>
>>>
>>> Also in testing words it appears to error on the listed Reserved Words,
>>> but some other words that are also fundamental to SQL such as “merge” do
>>> not error either and are not in the key word list.
>>>
>>>
>>>
>>>
>>>
>>> *Matthew Parker*
>>>
>>> *Chief Technologist*
>>>
>>> *Dimensional DBA*
>>>
>>> *Oracle Gold Partner*
>>>
>>> *425-891-7934 <(425)%20891-7934> (cell)*
>>>
>>> *D&B *047931344
>>>
>>> *CAGE *7J5S7
>>>
>>> *Dimensional.dba_at_comcast.net <Dimensional.dba_at_comcast.net>*
>>>
>>> *View Matthew Parker's profile on LinkedIn*
>>> <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>>>
>>> www.dimensionaldba.com
>>>
>>>
>>>
>>>
>>>
>>> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
>>> Behalf Of *Stefan Knecht
>>> *Sent:* Friday, March 16, 2018 10:14 PM
>>> *To:* oracle-l-freelists <oracle-l_at_freelists.org>
>>> *Subject:* PL/SQL Interpreter oddity - bug or "expected"?
>>>
>>>
>>>
>>> Ran into this recently, and personally I feel that this should not
>>> compile. What do you guys think?
>>>
>>>
>>>
>>> Simple case in point:
>>>
>>>
>>>
>>> create or replace package foo as
>>>
>>> procedure bar;
>>>
>>> end;
>>>
>>> /
>>>
>>>
>>>
>>> Package created.
>>>
>>>
>>>
>>>
>>>
>>> create or replace package body foo as
>>>
>>> procedure bar
>>>
>>> is
>>>
>>> begin
>>>
>>> begin
>>>
>>> null;
>>>
>>> end loop;
>>>
>>> end;
>>>
>>> end;
>>>
>>> /
>>>
>>>
>>>
>>> Package body created.
>>>
>>>
>>>
>>> show errors
>>>
>>>
>>>
>>> No errors.
>>>
>>>
>>>
>>> SQL> exec foo.bar
>>>
>>>
>>>
>>> PL/SQL procedure successfully completed.
>>>
>>>
>>>
>>>
>>>
>>> What is happening is that Oracle interprets the "end loop" as being "end
>>> anonymous_block_name". And in my opinion, with a keyword like "loop" that
>>> should not be happening. In essence, the above is interpreted as:
>>>
>>>
>>>
>>> create or replace package body foo as
>>>
>>> procedure bar
>>>
>>> is
>>>
>>> begin
>>>
>>> begin
>>>
>>> null;
>>>
>>> end anon_block_name;
>>>
>>> end;
>>>
>>> end;
>>>
>>> /
>>>
>>>
>>>
>>>
>>>
>>> If we switch the "end loop" to an "end if" (which is a similar flow
>>> control keyword) it reacts (in my opinion) correctly:
>>>
>>>
>>>
>>> create or replace package body foo as
>>>
>>> procedure bar
>>>
>>> is
>>>
>>> begin
>>>
>>> begin
>>>
>>> null;
>>>
>>> end if;
>>>
>>> end;
>>>
>>> end;
>>>
>>> /
>>>
>>>
>>>
>>> Warning: Package Body created with compilation errors.
>>>
>>>
>>>
>>> SQL> show errors
>>>
>>> Errors for PACKAGE BODY FOO:
>>>
>>>
>>>
>>> LINE/COL ERROR
>>>
>>> -------- ------------------------------------------------------------
>>> -----
>>>
>>> 7/7 PLS-00103: Encountered the symbol "IF" when expecting one of the
>>>
>>> following:
>>>
>>> ; <an identifier> <a double-quoted delimited-identifier>
>>>
>>> The symbol "IF" was ignored.
>>>
>>>
>>>
>>> SQL>
>>>
>>>
>>>
>>>
>>>
>>> Would you agree that that should not compile in the first place?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Stefan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> //
>>>
>>> zztat - The Next-Gen Oracle Performance Monitoring and Reaction
>>> Framework!
>>>
>>> Visit us at zztat.net | Support our Indiegogo campaign at
>>> igg.me/at/zztat | _at_zztat_oracle
>>>
>>
>>
>> --
>> //
>> zztat - The Next-Gen Oracle Performance Monitoring and Reaction
>> Framework!
>> Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
>> | _at_zztat_oracle
>> -- http://www.freelists.org/webpage/oracle-l
>
>
>
>
> --
> //
> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
> Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
> | _at_zztat_oracle
>

-- 
Best regards,
Sayan Malakshinov
Oracle performance tuning engineer
Oracle ACE Associate
http://orasql.org

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Mar 17 2018 - 16:29:22 CET

Original text of this message