Avoiding Inner Capture in DML Statements

In the following example, the reference to col2 in the inner SELECT statement binds to column col2 in table tab1 because table tab2 has no column named col2:

CREATE TABLE tab1 (col1 NUMBER, col2 NUMBER); CREATE TABLE tab2 (col1 NUMBER);

CREATE PROCEDURE proc AS

CURSOR c1 IS SELECT * FROM tab1

WHERE EXISTS (SELECT * FROM tab2 WHERE col2 = 10);

BEGIN

...

END;

In the preceding example, if you add a column named col2 to table tab2:

ALTER TABLE tab2 ADD (col2 NUMBER);

then procedure proc is invalidated and recompiled automatically upon next use. However, upon recompilation, the col2 in the inner SELECT statement binds to column col2 in table tab2 because tab2 is in the inner scope. Thus, the reference to col2 is captured by the addition of column col2 to table tab2.

Using collections and object types can cause more inner capture situations. In the following example, the reference to s.tab2.a resolves to attribute a of column tab2 in table tab1 through table alias s, which is visible in the outer scope of the query:

CREATE TYPE type1 AS OBJECT (a NUMBER); CREATE TABLE tab1 (tab2 type1);

CREATE TABLE tab2 (x NUMBER);

SELECT * FROM tab1 s -- alias with same name as schema name WHERE EXISTS (SELECT * FROM s.tab2 WHERE x = s.tab2.a);

-- note lack of alias

In the preceding example, you might add a column named a to table s.tab2, which appears in the inner subquery. When the query is processed, an inner capture occurs because the reference to s.tab2.a resolves to column a of table tab2 in schema s. You can avoid inner captures by following the rules given in "Avoiding Inner Capture in DML Statements" on page D-4. According to those rules, you should revise the query as follows:

SELECT * FROM s.tab1 p1

WHERE EXISTS (SELECT * FROM s.tab2 p2 WHERE p2.x = p1.tab2.a);

Same-Scope Capture

In SQL scope, a same-scope capture occurs when a column is added to one of two tables used in a join, so that the same column name exists in both tables. Previously, you could refer to that column name in a join query. To avoid an error, now you must qualify the column name with the table name.

Outer Capture

An outer capture occurs when a name in an inner scope, which once resolved to an entity in an inner scope, is resolved to an entity in an outer scope. SQL and PL/SQL are designed to prevent outer captures. You do not need to take any action to avoid this condition.

Avoiding Inner Capture in DML Statements

You can avoid inner capture in DML statements by following these rules:

D-4 PL/SQL User's Guide and Reference

Calling Parameterless Subprograms and Methods

Qualifying a reference with schema_name.table_name does not prevent inner capture if the statement refers to tables with columns of a user-defined object type.

Qualifying References to Object Attributes and Methods

Columns of a user-defined object type allow for more inner capture situations. To minimize problems, the name-resolution algorithm includes the following rules:

■All references to attributes and methods must be qualified by a table alias. When referencing a table, if you reference the attributes or methods of an object stored in that table, the table name must be accompanied by an alias. As the following examples show, column-qualified references to an attribute or method are not allowed if they are prefixed with a table name:

■Row expressions must resolve as references to table aliases. You can pass row expressions to operators REF and VALUE, and you can use row expressions in the SET clause of an UPDATE statement. Some examples follow:

The following ways to insert into an object table are allowed and do not require an alias because there is no column list:

Calling Parameterless Subprograms and Methods

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.

How PL/SQL Resolves Identifier Names D-5

Name Resolution for SQL Versus PL/SQL

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.

Name Resolution for SQL Versus PL/SQL

The name-resolution rules for SQL and PL/SQL are similar. You can avoid the few minor differences if you follow the capture avoidance rules.

For compatibility, the SQL rules are more permissive than the PL/SQL rules. That is, the SQL rules, which are mostly context sensitive, recognize as legal more situations and DML statements than the PL/SQL rules do.

D-6 PL/SQL User's Guide and Reference

E

PL/SQL Program Limits

This appendix discusses the program limits that are imposed by the PL/SQL language.

PL/SQL is based on the programming language Ada. As a result, PL/SQL uses a variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), a tree-structured intermediate language. It is defined using a meta-notation called Interface Definition Language (IDL). DIANA is used internally by compilers and other tools.

At compile time, PL/SQL source code is translated into machine-readable m-code. Both the DIANA and m-code for a procedure or package are stored in the database. At run time, they are loaded into the shared memory pool. The DIANA is used to compile dependent procedures; the m-code is simply executed.

In the shared memory pool, a package spec, object type spec, standalone subprogram, or anonymous block is limited to 2**26 DIANA nodes (which correspond to tokens such as identifiers, keywords, operators, and so on). This allows for ~6,000,000 lines of code unless you exceed limits imposed by the PL/SQL compiler, some of which are given in Table E–1.

Table E–1 PL/SQL Compiler Limits

PL/SQL Program Limits E-1

To estimate how much memory a program unit requires, you can query the data dictionary view user_object_size. The column parsed_size returns the size (in bytes) of the "flattened" DIANA. For example:

SQL> SELECT * FROM user_object_size WHERE name = 'PKG1';

NAME TYPE SOURCE_SIZE PARSED_SIZE CODE_SIZE ERROR_SIZE

--------------------------------------------------------------------

Unfortunately, you cannot estimate the number of DIANA nodes from the parsed size. Two program units with the same parsed size might require 1500 and 2000 DIANA nodes, respectively (because, for example, the second unit contains more complex SQL statements).

When a PL/SQL block, subprogram, package, or object type exceeds a size limit, you get an error such as program too large. Typically, this problem occurs with packages or anonymous blocks. With a package, the best solution is to divide it into smaller packages. With an anonymous block, the best solution is to redefine it as a group of subprograms, which can be stored in the database.

E-2 PL/SQL User's Guide and Reference

F

List of PL/SQL Reserved Words

The words listed in this appendix are reserved by PL/SQL. You should not use them to name program objects such as constants, variables, or cursors. Some of these words (marked by an asterisk) are also reserved by SQL. You should not use them to name schema objects such as columns, tables, or indexes.

List of PL/SQL Reserved Words F-1

F-2 PL/SQL User's Guide and Reference