I received this question yesterday:
Notice the line in blue and bold. I reference the package level variable, qualified with the package name (the approach that Tony has taken).
But then when Tony changes the name of the package, so he also has to change the dot-qualified references within the package.
Can you use "this" syntax, as is available in Java? No. You will see this error when trying to compile the package body:
"this"-style syntax is used only with object types in Oracle Database (our object-oriented extensions to the relational model), in which case you use "SELF" to reference the current object type instance.
So what should Tony do? Here are his (and mine, and your) options:
The compiler will try to resolve the reference to smallest inside proc. When that doesn't work, it will check the "next level up" in scope: the package body. Ah ha! There it is. And the body compiles.
Of course, this will not work as desired if you declare a variable or constant with the same name inside proc. The following version will also compile, but that reference to smaller inside proc will not refer to the package level variable.
In this case, you must qualify the variable with the scope you mean. You could qualify with the subprogram (procedure) or package name, by the way:
Of course, best of all is to avoid declaring variables with the same names at different scopes. That can be confusing - and then requires the use of dot-qualification. Another approach, frequently used, is to use different naming conventions for variables of different scope. For example, I commonly use "g_" to indicate a global variable in a package, and "l_" for local variables.
So my version of the package body would look like:
The most important thing is to be consistent in your approach so others (including the Future You) can more easily understand your code.
A final comment regarding dot-qualifying variable names: when you reference PL/SQL variables and constants inside SQL statements in your PL/SQL blocks, you should always qualify them with their scope names. Example:
By doing this, you give more information to the compiler that it can use to reduce the times when a program unit needs to be invalidated and recompiled. In the above package body, if I did not qualify my reference to n_in inside the SELECT, adding a column named "n_in" will cause the package body to be set to INVALID.
And upon recompilation, well, that reference to "n_in" will now be to the column and not your variable. Not good. By fully qualifying the reference, however, the compiler knows (via fine-grained dependency management, added in 11.1) that there can be no confusion, and adding a column to the employees table could not possibly disrupt the current behavior of the package body.
Is there a shortcut for referencing package variables in the package body? In Java, as an example, you can use the "this" keyword as a reference to the current object. This came about as I needed to create a copy of a package for debug purposes and realized I had to rename all the references to the package name within the package body.Before I answer, let's look at an example of what Tony is talking about. I create a package specification and then a body with package-level variable (declared outside any subprogram of the package):
CREATE OR REPLACE PACKAGE pkg
AUTHID DEFINER
IS
PROCEDURE proc (n_in IN NUMBER);
END;
/
CREATE OR REPLACE PACKAGE BODY pkg
IS
smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
BEGIN
IF n_in < pkg.smallest
THEN
DBMS_OUTPUT.put_line ('too small');
END IF;
END;
END;
/
Notice the line in blue and bold. I reference the package level variable, qualified with the package name (the approach that Tony has taken).
But then when Tony changes the name of the package, so he also has to change the dot-qualified references within the package.
Can you use "this" syntax, as is available in Java? No. You will see this error when trying to compile the package body:
PLS-00201: identifier 'THIS.SMALLEST' must be declared
"this"-style syntax is used only with object types in Oracle Database (our object-oriented extensions to the relational model), in which case you use "SELF" to reference the current object type instance.
So what should Tony do? Here are his (and mine, and your) options:
- Continue to dot qualify with the package name, and do a (careful, very careful) global search and replace of the old package name to new. Like I say: CAREFUL.
- Remove the package name. You don't need it.
That's right. You don't need to qualify the reference to this variable. In other words, this version of he package body will compile just fine:
CREATE OR REPLACE PACKAGE BODY pkg
IS
smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
BEGIN
IF n_in < smallest
THEN
DBMS_OUTPUT.put_line ('too small');
END IF;
END;
END;
/
The compiler will try to resolve the reference to smallest inside proc. When that doesn't work, it will check the "next level up" in scope: the package body. Ah ha! There it is. And the body compiles.
Of course, this will not work as desired if you declare a variable or constant with the same name inside proc. The following version will also compile, but that reference to smaller inside proc will not refer to the package level variable.
CREATE OR REPLACE PACKAGE BODY pkg
IS
smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
smallest NUMBER;
BEGIN
IF n_in < smallest
THEN
DBMS_OUTPUT.put_line ('too small');
END IF;
END;
END;
/
In this case, you must qualify the variable with the scope you mean. You could qualify with the subprogram (procedure) or package name, by the way:
CREATE OR REPLACE PACKAGE BODY pkg
IS
smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
smallest NUMBER;
BEGIN
IF n_in < proc.smallest -- references procedure's smallest
THEN
IF n_in < pkg.smallest -- references package level smallest
THEN
DBMS_OUTPUT.put_line ('too small');
END IF;
END;
END;
/
Of course, best of all is to avoid declaring variables with the same names at different scopes. That can be confusing - and then requires the use of dot-qualification. Another approach, frequently used, is to use different naming conventions for variables of different scope. For example, I commonly use "g_" to indicate a global variable in a package, and "l_" for local variables.
So my version of the package body would look like:
CREATE OR REPLACE PACKAGE BODY pkg
IS
g_smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
l_smallest NUMBER;
BEGIN
IF n_in < l_smallest -- references procedure's smallest
THEN
IF n_in < g_smallest -- references package level smallest
THEN
DBMS_OUTPUT.put_line ('too small');
END IF;
END;
END;
/
The most important thing is to be consistent in your approach so others (including the Future You) can more easily understand your code.
A final comment regarding dot-qualifying variable names: when you reference PL/SQL variables and constants inside SQL statements in your PL/SQL blocks, you should always qualify them with their scope names. Example:
CREATE OR REPLACE PACKAGE BODY pkg
IS
g_smallest NUMBER;
PROCEDURE proc (n_in IN NUMBER)
IS
l_salary NUMBER;
BEGIN
SELECT salary INTO l_salary
FROM employees e
WHERE e.employee_id = proc.n_in;
END;
END;
/
By doing this, you give more information to the compiler that it can use to reduce the times when a program unit needs to be invalidated and recompiled. In the above package body, if I did not qualify my reference to n_in inside the SELECT, adding a column named "n_in" will cause the package body to be set to INVALID.
And upon recompilation, well, that reference to "n_in" will now be to the column and not your variable. Not good. By fully qualifying the reference, however, the compiler knows (via fine-grained dependency management, added in 11.1) that there can be no confusion, and adding a column to the employees table could not possibly disrupt the current behavior of the package body.
I dislike using variables/parameters directly in DML statements like this for the similar reason of that _I_ dont necessarily know if "n_in" refers to a column or a variable. I had never considered what would happen if you added a new column to a table with that name..
ReplyDeleteInstead, if possible I try to use an explicit cursor with cursor parameters.
David, I don't think it is a good idea to choose the type of SQL access you are writing in your code to avoid un-intended name capture.
DeleteInstead, as I show above, you qualify *all* references inside the SQL statement - via table aliases and PL/SQL program / block name, and then you are 100% protected.
perhaps i phrased that badly..
DeleteI meant that if i end up with a query the needs to reference a variable, i will try to write it as an explicit cursor with parameters rather then reference the variable directly.
I got that, David. Perhaps it was I who was not as clear as could be.
DeleteI mean that, for example, implicit cursors (SELECT-INTO) are generally faster than explicit OPEN-FETCH-CLOSE. So to pick an explicit cursor when you could fully qualify variables and have no concerns whatsoever about inappropriate name capture in the future doesn't seem to me to be a good choice.