Parameter Aliasing
To optimize the subprogram call, the PL/SQL compiler can decide between the two techniques of the parameter passing. With the by-value techniques, the value of a real parameter is passed to the subprogram. With the by-reference techniques, only a pointer to the value is passed, in that case the actual and formal parameters reference the similar item.
The NOCOPY compiler hint increases the possibility of aliasing (i.e. having the two different names refer to the similar memory location). This can happen when a global variable appears as the actual parameter in a subprogram call and then is referenced within the subprogram. The result is indeterminate as it depends on the technique of parameter passing chosen by the compiler.
In the illustration below, the procedure add_entry refers to varray lexicon in two various ways: as the parameter and as a global variable. Therefore, if add_entry is called, the identifiers word_list & lexicon name the similar varray.
DECLARE
TYPE Definition IS RECORD (
word VARCHAR2(20),
meaning VARCHAR2(200));
TYPE Dictionary IS VARRAY(2000) OF Definition;
lexicon Dictionary := Dictionary();
PROCEDURE add_entry (word_list IN OUT NOCOPY Dictionary) IS
BEGIN
word_list(1).word := 'aardvark';
lexicon(1).word := 'aardwolf';
END;
BEGIN
lexicon.EXTEND;
add_entry(lexicon);
DBMS_OUTPUT.PUT_LINE(lexicon(1).word);
-- prints 'aardvark' if parameter was passed by value
-- prints 'aardwolf' if parameter was passed by reference
END;
The output depends on the technique of parameter passing chosen by the compiler. If the compiler chooses the by-value technique, word_list and lexicon are individual copies of the similar varray. Therefore, changing one does not affect the other. Whereas, if the compiler chooses the by-reference technique, word_list and lexicon are merely different names for the similar varray. (And Hence, the word "aliasing.")
The Aliasing can also occur if similar actual parameter appears more than once in a subprogram call. In the illustration below, n2 is an IN OUT parameter, therefore the value of the actual parameter is not updated till the procedure exits. This is why the first PUT_LINE prints 10 (the initial value of n) and the third PUT_LINE prints 20.
Though, n3 is a NOCOPY parameter, for this reason the value of the actual parameter is updated instantly. That is why the second PUT_LINE prints 30.
DECLARE
n NUMBER := 10;
PROCEDURE do_something (
n1 IN NUMBER,
n2 IN OUT NUMBER,
n3 IN OUT NOCOPY NUMBER) IS
BEGIN
n2 := 20;
DBMS_OUTPUT.PUT_LINE(n1); -- prints 10
n3 := 30;
DBMS_OUTPUT.PUT_LINE(n1); -- prints 30
END;
BEGIN
do_something(n, n, n);
DBMS_OUTPUT.PUT_LINE(n); -- prints 20
END;
As they are pointers, the cursor variables also increase the possibility of the aliasing. Consider the illustration below. Later the assignment, emp_cv2 is an alias of the emp_cv1 as both points to the similar query work region. Therefore, both can alter its position. So are why the first fetch from emp_cv2 fetches the third row and why the second fetch from emp_cv2 fails after you close emp_cv1.
PROCEDURE get_emp_data (
emp_cv1 IN OUT EmpCurTyp,
emp_cv2 IN OUT EmpCurTyp) IS
emp_rec emp%ROWTYPE;
BEGIN
OPEN emp_cv1 FOR SELECT * FROM emp;
emp_cv2 := emp_cv1;
FETCH emp_cv1 INTO emp_rec; -- fetches first row
FETCH emp_cv1 INTO emp_rec; -- fetches second row
FETCH emp_cv2 INTO emp_rec; -- fetches third row
CLOSE emp_cv1;
FETCH emp_cv2 INTO emp_rec; -- raises INVALID_CURSOR
...
END;