™ ™

Oracle8i PL/SQL — Ease-of-Use

and Application Development
An Oracle Technical White Paper
March 1999
OVERVIEW

The PL/SQL language, Oracle’s procedural extension to industry-standard SQL, is an easy-to-use,

full-fledged programming language that integrates many features, such as data encapsulation,
information hiding, overloading, and exception handling. The PL/SQL platform is a compelling
platform for application development for the following reasons:

•= PL/SQL provides seamless and tight integration with SQL, with natural, efficient, and safe
extensions to the SQL language.

•= An inherent strength that PL/SQL has is the power to evolve the language, which helps to naturally
and easily solve customer problems.

•= Embedded in the Oracle Server, the PL/SQL platform provides excellent support for PL/SQL stored
procedures as well as the ability to build scalable, portable, and highly robust Enterprise
applications on the server using these.

•= Embedded in the Oracle Developer™ and Oracle Developer Server™ products, the PL/SQL platform
provides a consistent application development environment, including the ability to drag and drop
procedures across tiers. PL/SQL procedures may be compiled and executed in the client or
middle tier.

As more and more applications deployed at the Enterprise level use PL/SQL heavily, there is an
increasing need to make the PL/SQL application development platform easier to use.

Oracle8i PL/SQL Release 8.1 includes a number of improvements that ease the development of
applications based on Oracle. Some of the improvements are transparent, allowing application
developers to benefit from these almost immediately, while some of the improvements involve new
language features that make programming applications much simpler. Oracle8i PL/SQL Release 8.1
™
also provides seamless interoperability with Java , executing in the server, and with C procedures,
executing in a separate process.

This paper focuses on the ease-of-use improvements and application development enhancements in
Oracle8i PL/SQL Release 8.1.

For a general overview of all Oracle8i PL/SQL Release 8.1 features, and for a discussion on future
directions, please refer to [1], an Oracle technical white paper on “Oracle8i PL/SQL - New Features
and Future Directions.”

Oracle8i PL/SQL — Ease-of-Use and Application Development 2

March 1999
Oracle8i PL/SQL Release 8.1 also includes a number of performance improvements. For a detailed
discussion on the performance of PL/SQL programs, please refer to [3], an Oracle technical white
paper on “Techniques for Tuning PL/SQL Applications.”

The following table summarizes the new Oracle8i PL/SQL Release 8.1 features that make PL/SQL
much easier to use:

Areas Features

Transparent •= Ability to compile much larger package bodies, by relaxing an internal limit
Ease-of-use that gave rise to the compilation time error “PLS-123: program too large”.

Enhancements •= Improved diagnostics for “ORA-6502: numeric or value error”, with the use of
additional subtext in many cases.

•= Enhanced ability to interoperate with older releases.

PL/SQL •= Improved callability from SQL, relating to purity and pragma

Language RESTRICT_REFERENCES. Transparent improvements (relaxed compilation
time restrictions) and simpler syntax.
Enhancements
•= Improved ability to write dynamic SQL code much more easily, using the new
native dynamic SQL feature, rather than the DBMS_SQL package interface.

•= Improved ability to log diagnostic messages at runtime much more easily, using
the new autonomous transactions feature.

•= Ability to create procedures that execute with the caller’s privileges (invoker-
rights procedures).

•= Ability to query local PL/SQL collection variables.

•= Enhanced extensibility of the database, using schema-level

user-defined operators.

•= Ability to write static methods in object types.

Oracle8i PL/SQL — Ease-of-Use and Application Development 3

March 1999
Interoperability •= Seamless interoperability with Java™.
with C, Java
•= Ability to pass object types, collection types, and REF types to external
C programs.

•= Additional mappings for basic types, when calling out to external

C procedures.

•= Ability to use Pro*C™ to write external procedures’ SQL callbacks much

more easily.

•= Ability to specify call-specifications that may be placed in the package and

type specifications, instead of just the body.

Tools for •= Support for tracing, profiling and performing code-coverage of PL/SQL
Application programs through the use of new “Probe” API extensions. These extensible,
open family of APIs, which included support for debugging in previous
rd
Development releases, may be used by 3 party vendors to build development environments
to debug and monitor PL/SQL programs

TRANSPARENT EASE-OF-USE IMPROVEMENTS

PACKAGE BODY SIZE LIMIT INCREASED

Prior to Oracle8i PL/SQL Release 8.1, the compilation of very large package and type bodies and
anonymous blocks resulted in the compilation time error “PLS-123: Program too large”, due to an
internal compiler limit. To work around this limitation, application developers split their packages
and type bodies into smaller units. In Oracle8i PL/SQL Release 8.1, this is no longer necessary,
because the internal compiler limit has now been substantially increased, allowing much larger
package and type bodies to be compiled. While it is not easy to correlate this internal limit with
number of lines of PL/SQL source code, it is estimated that an application developer would now be
able to write up to 6 millions lines of code in a single package or type body, provided other limits
aren’t reached. Note that the limit for other types of program units (schema-level functions and
procedures, package and type specs) has not been increased.

Oracle8i PL/SQL — Ease-of-Use and Application Development 4

March 1999
ORA-6502: NUMERIC OR VALUE ERROR MESSAGE IMPROVED

In Oracle8i PL/SQL Release 8.1, the runtime ORA-6502 error message that customers frequently
encounter is now improved to display subtext that state the reason (in most cases) why the error
occurred. This should help customers find problems in their code much more easily. For example:

declare

x varchar2(1);

begin

x := '12';

end;

Instead of seeing the more cryptic “ORA-6502: numeric or value error”, the application developer
will now see the following, much more informative error: “ORA-6502: PL/SQL: numeric or value
error: character string buffer too small”. In the case of:

declare

x number;

begin

x := 'abc';

end;

The application developer will see the following, much more friendly error: “ORA-6502: PL/SQL:
numeric or value error: character to number conversion error ”.

Subtexts for the ORA-6502 exceptions have been added for the most common ones that the PL/SQL
runtime engine throws, such as conversion errors. In future releases, Oracle expects to improve more
of the ORA-6502 messages, by adding more subtexts.

Oracle8i PL/SQL — Ease-of-Use and Application Development 5

March 1999
Note that the sub message text will be displayed for all unhandled ORA-6502 exceptions on the
client and server, and for handled exceptions on the server, via sqlerrm. This, however, will not occur
for handled exceptions on the client.

Although this new functionality doesn't implement the full blown parameterized exceptions
functionality that would be nice to have, it is an initial step in that direction, and should aid PL/SQL
developers who find the generic 6502 exception message hard to use.

IMPROVED INTEROPERABILITY

Although PL/SQL procedures and functions stored in an Oracle7™ database or an Oracle Developer
product containing PL/SQL Release 2.3 can make calls to all remote packaged procedures stored in a
remote database, they can call only those schema-level procedures that do not contain the use of any
new Oracle8™ features. In Oracle8i, this limitation no longer applies. This means that a procedure
stored in an Oracle7 or Oracle8 database, or an Oracle Developer product that contains PL/SQL
Release 2.3 or Release 8.0 may now call all remote procedures. This is true, regardless of whether the
remote procedures are packaged procedures or schema-level procedures and whether these remote
procedures contain the use of any new Oracle8i PL/SQL Release 8.1 features.

Oracle8i PL/SQL — Ease-of-Use and Application Development 6

March 1999
PL/SQL LANGUAGE ENHANCEMENTS

IMPROVED CALLABILITY FROM SQL - TRANSPARENT AND LANGUAGE SYNTAX

IMPROVEMENTS

The purity of a stored procedure refers to the side-effects of that procedure on database tables or
packaged variables. Various side-effects are disallowed when a function is called from a SQL query or
DML statement. This is discussed in [6] “Oracle8 Application Developer’s Guide, Release 8.0”.

The mechanism in Oracle7 and Oracle8 leveraged the PL/SQL compiler, to enforce restrictions
during the compilation of a stored procedure, or the compilation of a SQL statement. In Oracle8i
PL/SQL Release 8.1, the compilation time restrictions have been relaxed, and instead a smaller set of
restrictions are enforced during execution. This change was made with two goals in mind:

•= To provide uniform support for stored procedures written in PL/SQL, Java, and C.

•= To allow developers to worry less about PRAGMA RESTRICT_REFERENCES declarations.

In addition, many restrictions have been safely removed in order to allow programmers the most
flexibility possible.

In short, PRAGMA RESTRICT_REFERENCES is no longer required to allow a function to be

called from SQL. Instead, the Oracle8i server simply verifies during execution that:

•= A function called from a query (SELECT statement) or a parallelized DML statement does not
execute any DML or in any other way modify the database.

•= A function called from a query or DML statement does not end the current transaction, create or
rollback to a savepoint, or ALTER the system or session.

•= A function called from a DML statement does not read or modify the particular table that that DML
statement modifies.

Pragma RESTRICT_REFERENCES may still be used, if desired, to request that the PL/SQL
compiler identify statements or calls that have side-effects beyond those expected. A new keyword,
TRUST, has been added to the pragma RESTRICT_REFERENCES syntax. This allows the easy
calling of a subprogram that does not have the pragma from one that does by creating a wrapper
subprogram that uses the pragma with this new keyword that then calls the subprogram that does
not have the pragma.

Oracle8i PL/SQL — Ease-of-Use and Application Development 7

March 1999
In addition, two new keywords, DETERMINISTIC and PARALLEL_ENABLE, have been added to
the syntax for declaring a function. These are optimization hints to inform the query optimizer and
other aspects of Oracle8i about properties of the function.

•= The DETERMINISTIC keyword is a hint to indicate that the function returns results in a
deterministic manner and, therefore, need not be called redundantly. This functionality is new in
Oracle8i PL/SQL Release 8.1, and is used in the context of some new features, like
functional indexes.

•= The PARALLEL_ENABLE keyword is a hint to indicate that a function may be called from within
a parallel_query or parallel DML statement. In releases prior to Oracle8i PL/SQL Release 8.1, this
property was indicated in a somewhat non-obvious manner, via the WNPS and RNPS options of
the pragma RESTRICT_REFERENCES syntax.

Pragma RESTRICT_REFERENCES may still be used to request that the PL/SQL compiler identify
statements or calls that have side-effects beyond those expected.

Oracle8i PL/SQL — Ease-of-Use and Application Development 8

March 1999
NATIVE DYNAMIC SQL

Dynamic SQL refers to the ability to dynamically build and submit SQL statements for execution,
while in the midst of an execution of a PL/SQL procedure. Since the content of these statements can,
and probably will change with every execution, they are referred to as dynamic SQL statements.
Dynamic SQL statements may include data manipulation language (DML) statements (i.e., INSERT,
UPDATE, DELETE, SELECT), PL/SQL anonymous blocks, data definition language (DDL)
statements, transaction control statements, session control statements (with some restrictions), etc.

Dynamic SQL is very useful for applications that allow users to choose query search criteria or
optimizer hints at run time. Such uses are often required in database query tools, in interactive
database applications that present the user with information specific to their needs, and in
application code that is reusable and, therefore, independent of the actual SQL statement
being executed.

Prior to Oracle8i PL/SQL Release 8.1, the only way to program dynamic SQL statements inside
PL/SQL procedures involved the use of the programmatic interface provided through the
DBMS_SQL package. While this interface addresses the basic need for the dynamic SQL
functionality, it tends to be somewhat cumbersome to use, and generally results in code clutter and
code explosion.

Oracle8i PL/SQL Release 8.1 now provides the dynamic SQL capability directly through the PL/SQL
language, with new syntax and extensions of existing syntax. The new native dynamic SQL
functionality provides the following benefits over DBMS_SQL:

•= The new syntax is highly intuitive, much easier to use, and highly conducive to quick coding.

•= Programs written using the new functionality are a lot more compact, readable, and maintainable.

•= The performance of programs that use the new native dynamic SQL functionality is substantially
better than those that use the DBMS_SQL interface.

The PL/SQL language has been extended to support dynamic SQL in the following ways:

•= A new EXECUTE IMMEDIATE statement has been added, to allow the application developer to
prepare, execute, and deallocate a dynamic SQL statement. For example:

EXECUTE IMMEDIATE 'insert into ' || table_name || ' values

(:1, :2) ' USING val1, val2;
Note that the bind arguments to the dynamic SQL statement are specified in the USING clause.

Oracle8i PL/SQL — Ease-of-Use and Application Development 9

March 1999
 •= The syntax of the OPEN cursor statement has been extended to support the opening of ref cursor
variables on a dynamic SQL query that is specified as a string. For example:

OPEN ref_cursor_var

FOR 'select * from ' || table_name || ' where sal > :s '

USING salary;

•= The existing FETCH and CLOSE statements have been extended to support dynamic cursors
without any syntax changes.

The example below demonstrates the benefits of native dynamic SQL over the DBMS_SQL package:

DML Example using the Equivalent DML Example with

DBMS_SQL package Native Dynamic SQL

PROCEDURE insert_into_table ( PROCEDURE insert_into_table (

table_name VARCHAR2, table_name VARCHAR2,

deptnumber NUMBER, deptnumber NUMBER,

deptname VARCHAR2, deptname VARCHAR2,

location VARCHAR2 ) location VARCHAR2 )

IS IS

cur_hdl INTEGER; stmt_str VARCHAR2(200);

stmt_str VARCHAR2(200); BEGIN

rows_processed BINARY_INTEGER; stmt_str :=

BEGIN 'insert into ' || table_name || '

stmt_str := values (:deptno, :dname, :loc)';

'insert into ' || table_name ||

' values (:deptno, :dname, :loc)'; -- bundled execution using native

-- dynamic SQL

-- open cursor EXECUTE IMMEDIATE stmt_str

cur_hdl := dbms_sql.open_cursor; USING deptnumber, deptname, location;

Oracle8i PL/SQL — Ease-of-Use and Application Development 10

March 1999
 -- parse cursor END insert_into_table;

dbms_sql.parse(cur_hdl, stmt_str,

dbms_sql.native);

-- supply binds

dbms_sql.bind_variable(cur_hdl,

':deptno', deptnumber);

dbms_sql.bind_variable(cur_hdl,

':dname', deptname);

dbms_sql.bind_variable(cur_hdl,

':loc', location);

-- execute cursor

rows_processed :=

dbms_sql.execute(cur_hdl);

-- close cursor

dbms_sql.close_cursor(cur_hdl);

END insert_into_table;

The new dynamic SQL capability also provides significant performance improvements over
DBMS_SQL. Internal benchmarks using Oracle8i PL/SQL Release 8.1.3 demonstrated a 1.5 to 3.2
times improvement in performance. For more information about the performance benefits of this

Oracle8i PL/SQL — Ease-of-Use and Application Development 11

March 1999
feature, please refer to [3], an Oracle technical white paper on “Techniques for Tuning
PL/SQL Applications”.

For more details on the new native dynamic SQL capability, please refer to [2], an Oracle technical
white paper on “Native Dynamic SQL in PL/SQL”.

AUTONOMOUS TRANSACTIONS FOR BUILDING REUSABLE COMPONENTS AND

IMPROVED LOGGING

In many applications, it is often required to perform various logging operations (e.g., error logging,
audit logging) without being affected by the current transaction context. In releases prior to
Oracle8i PL/SQL Release 8.1, this functionality could be implemented only using DBMS_PIPE,
which required the calling procedure to communicate with a daemon process that performed the
logging in a separate session and transaction. While DBMS_PIPE is very powerful and flexible,
programming with DBMS_PIPE is often tedious and results in code that is cumbersome, hard to
read and maintain, and inefficient.

An application developer building an application with interacting components that perform

transactional operations is faced with the problem that these components could step over each other’s
transaction context. Prior to Oracle8i PL/SQL Release 8.1, there was no automatic way to isolate the
transactional activities of various components. It often required setting up contrived design and
coding practices that needed to be strictly adhered to. However, this often let to clumsy and
contrived designs that were error-prone. Consider a situation where an application developer wants
to build a component where a commit in that component does not also commit the transactional
changes of the calling component. Either the calling component would need to ensure that it is not
in the middle of a transaction when performing the call, or, if this is not possible, the components
would need to be redesigned, so that the called components would never perform commits. Instead
commits would need to be done as separate operations. Both choices result in contrived designs, and
leave room for error-prone coding.

Oracle8i introduces autonomous transactions, to much more effectively solve such problems. An
autonomous transaction is an independent transaction started within the context of another
transaction, the parent transaction. It shares no locks, resources, or commit-dependencies with the
parent transaction. Autonomous transactions provide all the functionality of regular transactions.
They also allow parallel queries, distributed processing, and all transaction control statements.

Oracle8i PL/SQL — Ease-of-Use and Application Development 12

March 1999
Oracle8i PL/SQL Release 8.1 exposes this feature through pragma AUTONOMOUS_TRANSACTION,
a new compiler directive. Using this pragma, PL/SQL schema level subprograms, local subprograms,
package or type methods and schema-level anonymous blocks may be declared as autonomous
transaction blocks. Upon entering an autonomous transaction block, the caller’s transaction context
is automatically suspended. Any subsequent SQL operations that need to be done within a
transaction will trigger the creation of a new autonomous transaction context. SQL operations may
then be performed, committed, or rolled back within the autonomous transaction context, with no
effect on the parent transaction. Although an autonomous transaction block may hold only one open
autonomous transaction context at any point during execution, the autonomous transaction block
may sequentially start and end several autonomous transactions. It may also call other autonomous
transaction blocks. Before exiting an autonomous transaction block, all autonomous transactions
must be explicitly committed or rolled back, or else an exception is raised upon exit. Upon exit from
the block, the parent transaction’s context is automatically restored, with no effect on the completed
autonomous transaction.

In performing logging operations, autonomous transactions provide a significant advantage over

DBMS_PIPE, as the resulting code is greatly simplified and much more efficient. A procedure that
starts an autonomous transaction may be called to log events that will stay committed even if the
parent transaction rolls back.

More importantly, autonomous transaction blocks help the application developer build modular
reusable software components that perform specialized transactional operations. This may be done
by writing stored procedures to independently start and finish autonomous transactions independent.
A calling application need not know about a procedure’s autonomous transactional operations, and
the procedure need not know about the calling application’s transaction context. This makes
autonomous transactions much less error-prone and much easier to use than regular transactions.

The following example illustrates a simple use of this feature:

CREATE OR REPLACE PROCEDURE debug_log1 (message VARCHAR2) AS

BEGIN

INSERT INTO debug_table VALUES (message);

END debug_insert1;

Oracle8i PL/SQL — Ease-of-Use and Application Development 13

March 1999
 CREATE OR REPLACE PROCEDURE debug_log2 (message VARCHAR2) AS

pragma AUTONOMOUS_TRANSACTION;

BEGIN

INSERT INTO debug_table VALUES (message);

commit;

END debug_insert1;

BEGIN

UPDATE emp SET sal = 1000000 WHERE ENAME = ‘KING’;

debug_log1(‘TRIED TO UPDATE SALARY OF KING TO 1000000 - log 1’);

UPDATE emp SET sal = 1000000 WHERE ENAME = ‘SMITH’;

debug_log2(‘TRIED TO UPDATE SALARY OF SMITH TO 1000000 - log 2’);

ROLLBACK;

/*

** At this point we lose all record of the fact that we attempted

** to change KING’s salary to 1000000 since debug_log1 does not

** use autonomous transactions.

** However, we do retain a record of the fact that we attempted

** to change SMITH’s salary to 1000000 since debug_log2 does

** use autonomous transactions.

*/

END;

Oracle8i PL/SQL — Ease-of-Use and Application Development 14

March 1999
INVOKER-RIGHTS PROCEDURES: INHERITING CALLER CONTEXT

Prior to Oracle8i, the only privilege and name-resolution context model that was supported was the
definer-rights model. In this model, a PL/SQL stored procedure may execute only with the privileges
of the user that created the procedure, and in the name-resolution context of that user’s schema.
Before allowing the procedure to execute any operation on a database object, Oracle verifies that the
procedure’s owner has the required privileges. In addition, stored procedures are bound to their
owner’s schema; i.e., unqualified object names are resolved in the procedure owner’s schema.
Definer-rights procedures help the application developer encapsulate access to database objects that
may not be public.

Oracle8i introduces a new complementary privilege and context model with invoker-rights procedures.
An invoker-rights procedure inherits the privileges and name-resolution context of the user from the
calling procedure. Although Oracle supplies several DBMS_* packages that behave like invoker-
rights packages (for instance, DBMS_SQL accepts a SQL string from a user and parses and executes it
on behalf of the user, despite being owned by SYS), the mechanism was internal and restricted to a
few packages in prior releases. Oracle8i formalizes and exposes these mechanisms to all users.
Invoker-rights stored procedures provide the ability to write and install a single copy of code that
multiple users can invoke to manipulate objects in different schemas, depending upon the calling
context. This can be extremely useful if an application must execute SQL on behalf of the user
calling it.

An invoker-rights procedure may be specified, using the new AUTHID clause. For example:

create or replace package sales AUTHID CURRENT_USER as ...

This clause may be used on a package or type specification, or on a schema-level procedure or

function. This clause may not be used on a package or type body, or on a nested
function or procedure.

The next few sub-sections walk the reader through a simple example that compares the two models.
Consider a company database that stores sales information for a number of regional company sales
offices. Sales data is stored in table SALES_TAB in each region’s schema, and accessed through
sales, an application package that encapsulates access to the data in SALES_TAB.

Oracle8i PL/SQL — Ease-of-Use and Application Development 15

March 1999
Definer’s Rights -> Code Duplication

ÿþýüûú ÿþýüûú ÿþýüûú

úü úü úü

ÿÿ ÿÿ ÿÿ

Figure 1. Sales database for a company with multiple regional sales offices.
Broken lines indicate package invocation. Solid lines indicate table access. A
separate copy of definer-rights package sales is installed in each region’s schema.

The application package sales must have the privileges to access SALES_TAB for each region. One
way to achieve this is to write sales as a definer-rights package, and then install a separate copy in
each region’s schema. In this case, the technique of code replication solves the access-rights problem,
at the cost of reduced maintainability.

Definer’s Rights -> Explicit Grants and Dynamic SQL

Alternatively, an application designer may choose to install a single copy of definer-rights package
sales in a central schema called COMPANY (see figure below). This requires two additional steps:

•= Each region must grant access on table SALES_TAB to schema COMPANY.

•= Sales must be extended (to a new version sales+), to take its calling context into account, i.e., each
invocation of sales must identify its region invoking it, and update SALES_TAB in that region. The
calling context may be passed in, to sales+, as an extra argument whose accuracy sales+ must be
able to verify.

Oracle8i PL/SQL — Ease-of-Use and Application Development 16

March 1999
 ÿþýüûú ÿþýüûú ÿþýüûú

ÿúü

ÿÿ ÿÿ

Figure 2. Sales database with a single copy of extended definer-rights package

sales+ in schema COMPANY. This implementation requires each REGION to grant
access on SALES_TAB to COMPANY.

Invoker’s Rights -> Automatic Calling Context Inheritance

If sales is implemented as an invoker-rights package, each invocation of sales inherits privileges and
name-resolution context from the user calling it (see figure below). In other words, if REGION1
invokes sales, each SQL operation (query, DDL or DML) in sales behaves as though REGION1
executes it. Access to SALES_TAB resolves to the table in REGION1, and is tested against user
REGION1’s rights.

ÿþýüûú ÿþýüûú ÿþýüûú

úü

ÿÿ ÿÿ

Figure 3. Sales database with a single copy of invoker-rights package sales in

schema COMPANY. Each invocation of sales inherits the privileges of its caller
and executes in the schema of its caller.

A Usage Tip For Invoker-Rights Programs

The application developer must be aware that any invoker-rights program that a user executes will
inherit all the privileges of the user, and can do anything that the user is able to do. Therefore, the
user must only execute such a program if the user trusts that it will not do something malicious.

Oracle8i PL/SQL — Ease-of-Use and Application Development 17

March 1999
SQL QUERIES ON A LOCAL VARIABLE OF A NESTED TABLE OR VARRAY TYPE

In releases prior to Oracle8i PL/SQL Release 8.0, queries may be performed only against database
tables. Starting with Oracle8i PL/SQL Release 8.1, Oracle provides support for SQL queries on local
variables of nested table or varray types. In other words, users can now specify a PL/SQL local
variable or parameter of a nested table or varray type, in the FROM clause of a SQL query. In Release
8.0, the syntax for doing this was somewhat clumsy and involved the use of the THE operator, which
Oracle plans to deprecate in a future release. In Release 8.1, a new, much improved syntax is now
available through the use of the TABLE() operator. This feature provides a powerful way of querying
dynamically created in-memory data.

The following example demonstrates this ability:

CREATE TYPE nt_vc2_20 AS TABLE OF VARCHAR2(20);

CREATE TABLE t_vc2 (a VARCHAR2(20));

DECLARE

lvnt nt_vc2_20 := nt_vc2_20(NULL);

BEGIN

lvnt(1) := 'ONE'; lvnt.extend;

lvnt(2) := 'TEN'; lvnt.extend;

lvnt(3) := 'HUNDRED';

-- syntax available starting with 8.1

INSERT INTO t_vc2

SELECT cast_lvnt.COLUMN_VALUE

FROM TABLE(CAST(lvnt AS NT_VC2_20)) cast_lvnt;

Oracle8i PL/SQL — Ease-of-Use and Application Development 18

March 1999
 -- syntax available starting with 8.0:

INSERT INTO t_vc2

SELECT cast_lvnt.COLUMN_VALUE

FROM THE(SELECT (CAST(lvnt AS NT_VC2_20))

FROM dual) cast_lvnt;

END;

Note that this feature is currently available only with nested table types and varray types but not
with PL/SQL index-by table types.

USER-DEFINED OPERATORS

In Oracle8i Release 8.1, users may define schema-level operators and bind them to PL/SQL functions.
These operators may subsequently be used in SQL statements wherever a SQL built-in operator is
allowed. Furthermore, one or more user-defined index types may optionally support an operator.
This means that an index of this index type can be used in efficiently evaluating these operators.
This feature is very important for specialized datatype developers. For example, Oracle's ConText™
datatype has implemented CONTAINS as a user-defined operator.

STATIC METHODS

Oracle8i PL/SQL Release 8.1 now supports the ability to define static methods, i.e., those that do not
have SELF as a parameter. Static methods are very useful in applications, since static methods that
logically belong to the object type, but do not operate on the SELF parameter, may now be packaged
in the object type itself.

Oracle8i PL/SQL — Ease-of-Use and Application Development 19

March 1999
INTEROPERABILITY WITH C, JAVA

The Oracle8 Server, Release 8.0 provides the ability to call, from PL/SQL stored procedures, C
external procedures executing in separate processes. Oracle8i PL/SQL, Release 8.1 additionally
provides the ability to call Java stored procedures executing in the server.

LANGUAGE ENHANCEMENTS COMMON TO CALLING BOTH JAVA AND C

PROGRAMS FROM PL/SQL

In Oracle8 Release 8.0, an application programmer was allowed to declare a procedure as

EXTERNAL (implemented in C) only where a PL/SQL procedure, or function body is considered
legal. This meant that an application developer could not declare an EXTERNAL procedure inside a
package (or type) specification. Oracle8i PL/SQL Release 8.1 introduces Call-Specifications, a
language extension that makes it much easier to call C procedures or Java methods from PL/SQL
procedures in the following ways:

•= The application programmer now has the option of providing the CALL-specification, either in a
PL/SQL package (or type) specification, or in a PL/SQL package (or type) body.

•= This new syntax allows an application developer to specify mappings from PL/SQL procedures to
procedures and methods in other languages (such as C and Java), consistently across these other
languages.

•= CALL-Specifications for C and Java procedures may coexist within a single PL/SQL package or type
specification, and may be called from either SQL or PL/SQL.

Here is an example of two CALL-Specifications (one for C and one for Java) in a single
package specification:

CREATE OR REPLACE PACKAGE call_spec_pack IS

PROCEDURE c_call (var1 NUMBER) IS

LANGUAGE C

LIBRARY some_c_library

NAME "c_call"

Oracle8i PL/SQL — Ease-of-Use and Application Development 20

March 1999
 PARAMETERS(var1 OCINUMBER, var1 INDICATOR SHORT);

PROCEDURE java_call(var1 NUMBER) IS

LANGUAGE JAVA

NAME 'java_call_class.java_call(oracle.sql.NUMBER)';

END call_spec_pack;

ENHANCEMENTS SPECIFIC TO CALLING C PROGRAMS

In Oracle8i PL/SQL Release 8.1, it is now much easier to call C programs from PL/SQL procedures:

•= Complete support for Oracle8 objects and collections types: Oracle8 objects and collection types may now
be passed to the external procedure. New objects and collections may be returned from the external
procedure as IN/OUT, OUT, and RETURN arguments.

•= Support for additional mappings: PL/SQL type NUMBER to C type OCINumber; PL/SQL type
DATE to C type OCIDate; PL/SQL types VARCHAR2, LONG and CHAR to OCIString; PL/SQL
types RAW and LONG RAW to C type OCIRaw.

•= Caching of DLLs for improved external procedure performance: Oracle8i external procedures transparently
cache up to ten DLLs in a session. Subsequent calls to a C function in a cached DLL will not cause
the DLL to be reloaded, thereby significantly improving external procedure performance.

•= Support for Pro*C to execute SQL callbacks into the database: Prior to Release 8.1, external procedures
could call back into the database only through OCI. In release 8.1, external procedures now support
Pro*C to callback into the database. Writing Pro*C to execute external procedures SQL callbacks is
substantially easier than writing OCI8 callbacks.

Here is a simple example of a Pro*C callback:

void UpdateEmp (with_context, empnumber, empnumberind)

OCIExtProcContext *with_context;

OCINumber *empnumber;

short empnumberind;

Oracle8i PL/SQL — Ease-of-Use and Application Development 21

March 1999
 exec sql register connect using :with_context;

exec sql

update emp set empno = 999

where empno = :empnumber:empnumberind;

....

....

INTEROPERABILITY WITH JAVA IN THE SERVER

Oracle8i provides strong support for Java in all tiers, including Java stored procedures, with a Java
Virtual Machine (VM) executing in the server. Oracle8i PL/SQL and Java interoperate seamlessly
and complement each other in the database. Consistent with Oracle’s theme of “language
transparency”, Oracle addresses PL/SQL and Java interoperability in two ways:

•= Application level interoperability: PL/SQL and SQL can call Java methods by registering call
specifications for the Java class. Java can also call PL/SQL and SQL, either through the JDBC
interface or through the use of SQLJ. In the future, Oracle plans to allow PL/SQL and Java stored
procedures in the server to be debugged transparently.

•= Shared services between the Java and PL/SQL execution engines: Within the server, the Java Virtual
Machine and the PL/SQL engine already share a number of common services, to provide users with
optimal performance and scalability.

For more details, please refer to [5], an Oracle technical white paper on “Multi-Language Program
Development in Oracle8i”.

Oracle8i PL/SQL — Ease-of-Use and Application Development 22

March 1999
TOOLS FOR APPLICATION DEVELOPMENT

The Probe family of APIs provides a broad range of low level services that can help tools builders
build development environments to debug and monitor PL/SQL applications. The first of these
APIs was the debugger API, which has been available since PL/SQL Release 2.3.4. The Oracle
Procedure Builder product integrates with this, to provide a PL/SQL debugger.

New APIs have been added to Oracle8i PL/SQL Release 8.1, to support PL/SQL profiling, code
coverage, and profiling. These APIs are being made available to tools vendors.

PL/SQL AND THE INTERNET

For information on how to use the PL/SQL cartridge with the Oracle Application Server to develop
Web applications using PL/SQL, please refer to [4], an Oracle technical white paper on “Developing
Web Applications Using PL/SQL”.

SUMMARY

Oracle8i PL/SQL Release 8.1 includes many features that improve ease of use and application
development. In addition, this new release includes a number of performance improvements. For
details, please refer to [3], an Oracle technical white paper on “Techniques for Tuning PL/SQL
Applications”. For more details on all the new functionality, please refer to [7] “Oracle8i
Application Developer’s Guide - Fundamentals, Release 8.1.5”, [8] “Oracle8i Concepts, Release
8.1.5”, and [9] “PL/SQL User’s Guide and Reference, Release 8.1.5”. Oracle intends to fully support,
enhance, and extend PL/SQL, to make it even easier to use, perform even faster, and, in general,
much better.

Oracle8i PL/SQL — Ease-of-Use and Application Development 23

March 1999
ACKNOWLEDGEMENTS

The authors of this paper, Usha Sangam (editor), Guhan Viswanathan, Dave Alpern, Kannan
Muthukkaruppan, Neil Le, Ron Decker, Radhakrishna Hari and Chandrasekharan Iyer thank Shirish
Puranik and Ashok Swaminathan for their review comments and suggestions for improvements to
this paper.

REFERENCES

1. Oracle8i PL/SQL - New Features and Future Directions - an Oracle Technical White Paper,
February 1999

2. Native Dynamic SQL: A Better Alternative to DBMS_SQL - an Oracle Technical White Paper,
January 1999

3. Techniques for Tuning PL/SQL Applications - an Oracle Technical White Paper, November 1998

4. Developing Web Applications Using PL/SQL - an Oracle Technical White Paper, January 1999

5. Multi-Language Application Development in Oracle8i - an Oracle Technical White Paper,

January 1999

6. Oracle8 Application Developer’s Guide, Release 8.0

7. Oracle8i Application Developer’s Guide - Fundamentals, Release 8.1.5

8. Oracle8i Concepts, Release 8.1.5

9. PL/SQL User’s Guide and Reference, Release 8.1.5

Oracle8i PL/SQL — Ease-of-Use and Application Development 24

March 1999
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
+1.650.506.7000
Fax +1.650.506.7200
http://www.oracle.com/

Copyright © Oracle Corporation 1999

All Rights Reserved

This document is provided for informational purposes only, and

the information herein is subject to change without notice.
Please report any errors herein to Oracle Corporation. Oracle
Corporation does not provide any warranties covering and
specifically disclaims any liability in connection with this
document.

Oracle is a registered trademark, and Oracle8i, Oracle8, PL/SQL,

and Oracle Expert are trademarks or registered trademarks of
Oracle Corporation. All other company and product names
mentioned are used for identification purposes only and may be
trademarks of their respective owners.