Managing Packages

With PL/SQL, you can break an application down into manageable, well-defined modules. Using PL/SQL code, you can write program units that are stored as database objects that can be reused. These objects include packages, subprograms, and triggers. Subprograms and packages are discussed in this topic; triggers are discussed in Triggers: Usage Information.

When writing packages, keep them general so they can be reused in future applications. Become familiar with the Oracle-supplied packages, and avoid writing packages that duplicate features already provided by Oracle.

Design and define package specs before the package bodies. Place in a spec only those things that must be visible to calling programs. That way, other developers cannot build unsafe dependencies on your implementation details.

To reduce the need for recompiling when code is changed, place as few items as possible in a package spec. Changes to a package body do not require recompiling calling procedures. Changes to a package spec require Oracle to recompile every stored subprogram that references the package.

Calling Subprograms in Packages

Packages are stored in the database, where they can be shared by many applications. Calling a packaged subprogram for the first time loads the whole package and caches it in memory, saving on disk I/O for subsequent calls. Thus, packages enhance reuse and improve performance in a multiuser, multi-application environment.

If a subprogram does not take any parameters, you can include an empty set of parentheses or omit the parentheses, both in PL/SQL and in functions called from SQL queries. For calls to a method that takes no parameters, an empty set of parentheses is optional within PL/SQL scopes but required within SQL scopes.

Accessing Variables in Packages

You can create a package specification that is designated only to supply common variables to other packages or subprograms. With the variables in one package, they can be easily maintained for all subprograms that use the variables, rather than maintaining the variables in all the individual subprograms. These common variables are typically used in multiple subprograms, such as a sales tax rate.

In Example: Using Variables in Packages, the variables my_pi and my_e can be used by any subprogram. If you change the value of my_pi or my_e, then all subprograms that use the variable get the new value without having to change anything in those individual subprograms.

Note that you need to use of the package name as a prefix to the variable name, such as my_pkg.my_pi.

Using Variables in Packages

CREATE PACKAGE my_pkg AS
  my_pi        NUMBER := 3.14016408289008292431940027343666863227;
  my_e         NUMBER := 2.71828182845904523536028747135266249775;
  my_sales_tax NUMBER := 0.0825
END my_pkg;
/

CREATE PROCEDURE circle_area(radius NUMBER) IS
  my_area NUMBER;
  my_datatype VARCHAR2(30);
BEGIN
  my_area := my_pkg.my_pi * radius;
  DBMS_OUTPUT.PUT_LINE('Radius: ' || TO_CHAR(radius) 
                       || ' Area: ' || TO_CHAR(my_area) );
END;
/
-- call the circle_area procedure with radius equal to 3
CALL circle_area(3);
-- call the circle_area procedure with radius equal to 4
BEGIN
  circle_area(3);
END;
/
-- cleanup: drop package and procedure
DROP PROCEDURE circle_area;
DROP PACKAGE my_pkg;