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

From: <rogel_at_web.de>
Date: Sat, 17 Mar 2018 15:39:09 +0100
Message-ID: <trinity-93e5893f-baa6-4a7c-84c6-d84ca7374e5e-1521297549353_at_3c-app-webde-bs62>


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 (cell)

D&B 047931344

CAGE 7J5S7

Dimensional.dba_at_comcast.net

View Matthew Parker's profile on LinkedIn

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 Received on Sat Mar 17 2018 - 15:39:09 CET

Original text of this message