Conference ulysse::rdb_vms_competition

302.0. "Oracle PL/SQL Information" by MAIL::DUNCANG (Gerry Duncan @KCO) Sat Feb 11 1989 22:42

A few days ago I reviewed most of the V6/TPO manual set.  I was specifically 
looking for anything concerning PL/SQL.  My customer did not receive a PL/SQL
manual.  However, there are several references to functionality and syntax in
the Oracle messages guide, SQL*plus, and DBA reference.  Here's what I was able
to piece together.

PL/SQL is a programming language.  In the example below (copied from one of the 
manuals), it appears very similar to RDO FOR loops.  According to the manuals,
PL/SQL is a "procedural superset of SQL" and has the following functionality: 

	- Variables can be declared and assigned values
	- Conditional control (IF, THEN, ELSE)
	- Looping
	- Exception handling

PL/SQL Terms:
-------------

BLOCK (programs) are submitted to the runtime. Once received, the
	blocks are parsed and executed.  If the block is to be handled by
	a remote database, it is passed to the remote note before parsing.
	This is supposed to reduce the number of messages to/from your 
	application and the runtime. (Does this mean that their call structure
	is inefficient ???)

FUNCTIONS appear to be user defined items such as MIN, MAX, etc.

PROCEDURES ???

DECLARE starts the definition of a block, function, or procedure.

CASE, WHEN, LOOP, EXIT, RETURN, and GOTO allow flow control

CALL for nesting.


Example PL/SQL "block":
----------------------
This example was illustrated as a part of an interactive SQL session.  

DECLARE
	X	NUMBER := 100;
	BEGIN
		FOR i IN 1..10 LOOP
			IF TRUNC(i / 2) = i / 2   THEN
				INSERT INTO temp VALUES( list of values)
			ELSE
				INSERT INTO temp VALUES( list of values)	
			END IF;
		X  := X + 100;
	END LOOP;
END;
.

The PL/SQL "block" must end with a period (.).  The lower case items appear
to be variables or parameters.  PL/SQL statements end with semicolon (;).

I imagine that you'll be able to store these "blocks, procedures, and
functions" in some sort of Oracle "system relation". One could also store the
"block" in a .SQL file and execute it as an indirect much like VMS DCL @
functionality.  Since it allows table manipulation (via SQL statements) to be
imbedded in a "block", a user could easily write "blocks" without using a
traditional 3GL language.   Further, I would image that SQL*forms trigger
functionality will be expanded to allow "block" execution.  (This may explain
why a customer who receives SQL*froms V3 will automatically receive PL/SQL
whether or not they have purchased V6 with the TPO option. That means that
ALL V6.TPO provides is row level locking.) 

The 6.0.25 release my customer installed has a PLSQL.OLB libaray located in the
precompiler directory.  This would lead me to believe that there may be a
precompiler available such that this little language would APPEAR, at first
glance, the same as our SQL module language.

I reviewed the error message guide to look for clues and noticed that many of 
the functions and features WILL NOT be available for the V1.0 release.  I
would estimate that 1/5 of the error messages had the following explanation:

	"... this feature will no be included in PL/SQL V1.0 ..."

Some of the features listed as NOT being available in V1.0 include:
	- CASE
	- WHEN
	- RETURN
	- FUNCTIONS
	- PROCEDURES

I can't imagine printing a manual with so much of this "future" crap in it.
If Oracle is making so much money and are so good, why would the embarrass
themselves by this unprofessional approach.  Wonder if they're trying to
save on manual costs ?

Oh, well, This is just a preliminary look at this PROPRIETARY language and I'll
reply more when I see the actual manual. 

--gerry