Professional Documents
Culture Documents
PRAGMA RESTRICT_REFERENCES allows us to explicitly declare that a PL/SQL program doesnt read/write in
db objects or in package variables.
In some situations, only functions that guarantee those restrictions can be used.
The following is a simple example:
Lets define a package made of a single function that updates a db table and returns a number:
1
SQL> create or replace package pack is
2
2 function a return number;
3
3 end;
4
4 /
5
6
SQL> create or replace package body pack is
7
2 function a return number is
8
3 begin
9
4 update emp set empno=0 where 1=2;
10
5 return 2;
11
6 end;
12
7 end;
13
8 /
If we try to use the function pack.a in a query statement well get an error:
1 SQL> select pack.a from dual;
2 select pack.a from dual
3
*
4 ERROR at line 1:
5 ORA-14551: cannot perform a DML operation inside a query
6 ORA-06512: a "MAXR.PACK", line 4
PL/SQL functions can be used inside a query statement only if they dont modify neither the db nor packages
variables.
This error can be descovered only at runtime, when the select statement is executed.
How can we check for this errors at compile time? We can use PRAGMA RESTRICT_REFERENCES!
If we know that the function will be used in SQL we can define it as follows:
1 SQL> create or replace package pack is
2
2 function a return number;
3
3 pragma restrict_references(a,'WNDS');
4
4 end;
5
5 /
Declaring that the function A will not modify the database state (WNDS stands for WRITE NO DATABASE
STATE).
Once we have made this declaration, if a programmer, not knowing that the function has to be used in a query
statement, tries to write code for A that violates the PRAGMA:
1
SQL> create or replace package body pack is
2
2 function a return number is
3
3 begin
4
4 update emp set empno=0 where 1=2;
5
5 return 2;
6
6 end;
7
7 end;
8
8 /
9
10 Warning: Package Body created with compilation errors.
11
12 SVIL>sho err
13 Errors for PACKAGE BODY PACK:
14
15 LINE/COL ERROR
16 -------- ----------------------------------------------------------------17 2/1
PLS-00452: Subprogram 'A' violates its associated pragma
He(She)ll get an error at compile time
Pragma RESTRICT_REFERENCE is deprecated and could be removed from future versions of Oracle.
PRAGMA SERIALLY_REUSABLE tells to the compiler that the packages variables are needed for a single use.
After this single use Oracle can free the associated memory. Its really useful to save memory when a packages
uses large temporary space just once in the session.
Lets see an example.
Lets define a package with a single numeric variable var not initialized:
1 SQL> create or replace package pack is
2
2 var number;
3
3 end;
4
4 /
If we assign a value to var, this will preserve that value for the whole session:
1 SQL> begin
2
2 pack.var := 1;
3
3 end;
4
4 /
5
6 SQL> exec dbms_output.put_line('Var='||pack.var);
7 Var=1
If we use the PRAGMA SERIALLY_REUSABLE, var will preserve the value just inside the program that initializes
it, but is null in the following calls:
1
SQL> create or replace package pack is
2
2 PRAGMA SERIALLY_REUSABLE;
3
3 var number;
4
4 end;
5
5 /
6
7
SQL> begin
8
2 pack.var := 1;
9
3 dbms_output.put_line('Var='||pack.var);
10
4 end;
11
5 /
12 Var=1
13
14 SQL> exec dbms_output.put_line('Var='||pack.var);
15 Var=
PRAGMA SERIALLY_REUSABLE is a way to change the default behavior of package variables that is as useful
as heavy for memory.
PRAGMA AUTONOMOUS_TRANSACTION declare to the compiler that a given program has to run into a
dedicated transaction, ignoring all uncommitted data changes made into the original transaction of the calling
program.
The sum of salaries in EMP is:
1 SQL> select sum(sal) from emp;
2
3
SUM(SAL)
4 ---------5
29025
Lets define two functions that do exactly the same thing, read and return the sum of salaries of EMP:
1
SQL> create or replace function getsal return number is
2
2 s number;
3
3 begin
4
4 select sum(sal) into s from emp;
5
5 return s;
6
6 end;
7
7 /
8
9
SQL> create or replace function getsal_AT return number is
10
2 PRAGMA AUTONOMOUS_TRANSACTION;
11
3 s number;
12
4 begin
13
5 select sum(sal) into s from emp;
14
6 return s;
15
7 end;
16
8 /
17
18 SQL> select sum(sal), getsal, getsal_AT
19
2 from emp;
20
21
SUM(SAL) GETSAL GETSAL_AT
22 ---------- ---------- ---------23
29025
29025
29025
The second one uses the PRAGMA AUTONOMOUS_TRANSACTION. Now lets cut all the salaries:
1 SQL> update emp set sal=10;
2
3 SQL> select sum(sal), getsal, getsal_AT
4
2 from emp;
5
6
SUM(SAL) GETSAL GETSAL_AT
6 end;
Subprogram inlining behave differently depending on the level of optimization defined through the db initialization
variable PLSQL_OPTIMIZE_LEVEL.
If this variable is set to 2 (thats the default value) optimizer never uses subprogram inlining unless the
programmer requests it using PRAGMA INLINE YES.
If PLSQL_OPTIMIZE_LEVEL=3 optimizer can autonomously decide whether to use subprogram inlining or not.
In this case PRAGMA INLINE YES does not force the optimizer, its just an hint.
Thats all about pragmas by now.