View
235
Download
0
Category
Preview:
Citation preview
8/14/2019 o8i plsql app dev twp
1/25
Oracle8 iPL/SQL
Ease-of-Use
and Application Development
An Oracle Technical White Paper
M arch 199 9
8/14/2019 o8i plsql app dev twp
2/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
2
OVERVIEW
The PL/SQL language, Oracles 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 safeextensions to the SQL language.
= An inherent strength that PL/SQL has is the power to evolve the language, which helps to naturallyand easily solve customer problems.
= Embedded in the Oracle Server, the PL/SQL platform provides excellent support for PL/SQL storedprocedures 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 platformprovides 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 Oracle8 i PL/SQL - New Features
and Future Directions.
8/14/2019 o8i plsql app dev twp
3/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
3
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
Ease-of-use
Enhancements
= Ability to compile much larger package bodies, by relaxing an internal limitthat gave rise to the compilation time error PLS-123: program too large.
= Improved diagnostics for ORA-6502: numeric or value error, with the use ofadditional subtext in many cases.
= Enhanced ability to interoperate with older releases.PL/SQL
Language
Enhancements
= Improved callability from SQL, relating to purity and pragmaRESTRICT_REFERENCES. Transparent improvements (relaxed compilation
time restrictions) and simpler syntax.
= Improved ability to write dynamic SQL code much more easily, using the newnative dynamic SQL feature, rather than the DBMS_SQL package interface.
= Improved ability to log diagnostic messages at runtime much more easily, usingthe new autonomous transactions feature.
= Ability to create procedures that execute with the callers 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.
8/14/2019 o8i plsql app dev twp
4/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
4
Interoperability
with C, Java
= Seamless interoperability with Java.= Ability to pass object types, collection types, and REF types to external
C programs.
= Additional mappings for basic types, when calling out to externalC procedures.
= Ability to use Pro*C to write external procedures SQL callbacks muchmore easily.
= Ability to specify call-specifications that may be placed in the package andtype specifications, instead of just the body.
Tools for
Application
Development
= Support for tracing, profiling and performing code-coverage of PL/SQLprograms through the use of new Probe API extensions. These extensible,
open family of APIs, which included support for debugging in previous
releases, may be used by 3rd party vendors to build development environments
to debug and monitor PL/SQL programs
TRANSPARENT EASE-OF-USE IMPROVEMENTS
PACKAGE BOD Y 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
arent reached. Note that the limit for other types of program units (schema-level functions and
procedures, package and type specs) has not been increased.
8/14/2019 o8i plsql app dev twp
5/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
5
ORA-6502: NUM ERIC OR VALUE ERROR M ESSAGE 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.
8/14/2019 o8i plsql app dev twp
6/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
6
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 Oracle8 i PL/SQL Release 8.1 features.
8/14/2019 o8i plsql app dev twp
7/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
7
PL/SQL LAN GUA GE ENHA NCEM ENTS
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 Developers 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 notexecute 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 orrollback 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 DMLstatement 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.
8/14/2019 o8i plsql app dev twp
8/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
8
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 adeterministic 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 withina 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.
8/14/2019 o8i plsql app dev twp
9/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
9
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/SQLlanguage, 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 toprepare, 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.
8/14/2019 o8i plsql app dev twp
10/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
10
= The syntax of the OPEN cursor statement has been extended to support the opening of ref cursorvariables 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 cursorswithout any syntax changes.
The example below demonstrates the benefits of native dynamic SQL over the DBMS_SQL package:
DML Example using the
DBMS_SQL package
Equivalent D M L Example w ith
Native Dynamic SQL
PROCEDURE insert_into_table (
table_name VARCHAR2,
deptnumber NUMBER,
deptname VARCHAR2,
location VARCHAR2 )
IS
cur_hdl INTEGER;
s tm t_s tr VA RC HAR 2(2 00 );
rows_processed BINARY_INTEGER;
BEGIN
stmt_str :=
'insert into ' || table_name ||
' values (:deptno, :dname, :loc)';
-- open cursor
cur_hdl := dbms_sql.open_cursor;
PROCEDURE insert_into_table (
table_name VARCHAR2,
deptnumber NUMBER,
deptname VARCHAR2,
location VARCHAR2 )
IS
stmt_str VARCHAR2(200);
BEGIN
stmt_str :=
'insert into ' || table_name || '
values (:deptno, :dname, :loc)';
-- bundled execution using native
-- dynamic SQL
EXECUTE IMMEDIATE stmt_str
USING deptnumber, deptname, location;
8/14/2019 o8i plsql app dev twp
11/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
11
-- parse cursor
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;
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
8/14/2019 o8i plsql app dev twp
12/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
12
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 REUSA BLE COMPON ENTS AN DIM PROVED 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 others
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 sett ing 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.
8/14/2019 o8i plsql app dev twp
13/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
13
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 callers 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 transactions 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 result ing 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 procedures autonomous transactional operations, and
the procedure need not know about the calling applications 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;
/
8/14/2019 o8i plsql app dev twp
14/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
14
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 KINGs 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 SMITHs salary to 1000000 since debug_log2 does
** use autonomous transactions.
*/
END;
/
8/14/2019 o8i plsql app dev twp
15/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
15
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 users schema.
Before allowing the procedure to execute any operation on a database object, Oracle verifies that the
procedures owner has the required privileges. In addit ion, stored procedures are bound to their
owners schema; i.e., unqualified object names are resolved in the procedure owners 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-right s 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 regions schema, and accessed through
sales, an application package that encapsulates access to the data in SALES_TAB.
8/14/2019 o8i plsql app dev twp
16/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
16
Definers 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 regions 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 regions schema. In this case, the technique of code replication solves the access-rights problem,
at the cost of reduced maintainability.
Definers 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 ofsales 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.
8/14/2019 o8i plsql app dev twp
17/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
17
Figure 2. Sales database with a single copy of extended definer-rights packagesales+ in schema COMPANY. This implementation requires each REGION to grant
access on SALES_TAB to COMPANY.
Invokers Rights -> Automatic Calling Context Inheritance
Ifsales is implemented as an invoker-rights package, each invocation ofsales 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
REGION1s 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 callerand 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.
8/14/2019 o8i plsql app dev twp
18/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
18
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;
8/14/2019 o8i plsql app dev twp
19/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
19
-- 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 M ETHODS
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.
8/14/2019 o8i plsql app dev twp
20/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
20
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 CPROGRAMS 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 aPL/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 toprocedures 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 typespecification, 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"
8/14/2019 o8i plsql app dev twp
21/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
21
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;
ENHA NCEMENTS 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 nowbe 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 typeDATE 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 D LLs for improved external procedure performance: Oracle8i external procedures transparentlycache 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 procedurescould 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;
{
8/14/2019 o8i plsql app dev twp
22/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
22
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 Oracles theme of language
transparency, Oracle addresses PL/SQL and Java interoperability in two ways:
= A pplication level interoperabili ty: PL/SQL and SQL can call Java methods by registering callspecifications for the Java class. Java can also call PL/SQL and SQL, either through the JDBCinterface 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 VirtualMachine 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.
8/14/2019 o8i plsql app dev twp
23/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
23
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 AN D 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 Developers Guide - Fundamentals, Release 8.1.5, [8] Oracle8i Concepts, Release
8.1.5, and [9] PL/SQL Users 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.
8/14/2019 o8i plsql app dev twp
24/25
Oracle8i PL/ SQL Ease-of-Use and Application Development
March 1999
24
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 Developers Guide, Release 8.0
7. Oracle8i Application Developers Guide - Fundamentals, Release 8.1.5
8. Oracle8i Concepts, Release 8.1.5
9. PL/SQL Users Guide and Reference, Release 8.1.5
8/14/2019 o8i plsql app dev twp
25/25
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065U.S.A.
Worldwide Inquiries:
+1.650.506.7000
Fax +1.650.506.7200
http:// ww w.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 warrant ies covering and
specifically disclaims any liability in connection w ith t his
document.
Oracle is a registered trademark, and Oracle8i, Oracle8, PL/SQL,
and Oracle Expert are t rademarks or registered trademarks of
Oracle Corporation. All other company and product names
mentioned are used for identi fication purposes only and may be
trademarks of their respective owners.
Recommended