Pl/sql boolean expression short circuit behavior and the 10g optimizer

Question

Oracle documents that a PL/SQL IF condition such as
IF p OR q
will always short circuit if p is TRUE. The documents confirm that this is also true for CASE and for COALESCE and DECODE (although DECODE is not available in PL/SQL).
Charles Wetherell, in his paper "Freedom, Order and PL/SQL Optimization," (available on OTN) says that "For most operators, operands may be evaluated in any order. There are some operators (OR, AND, IN, CASE, and so on) which enforce some order of evaluation on their operands."
My questions:
(1) In his list of "operators that enforce some order of evaluation," what does "and so on" include?
(2) Is short circuit evaluation ALWAYS used with Boolean expressions in PL/SQL, even when they the expression is outside one of these statements? For example:
boolvariable := p OR q;
Or:
CALL foo(p or q);

Answer 1

This is a very interesting paper. To attempt to answer your questions:-
1) I suppose BETWEEN would be included in the "and so on" list.
2) I've tried to come up with a reasonably simple means of investigating this below. What I'm attempting to do it to run a series of evaluations and record everything that is evaluated. To do this, I have a simple package (PKG) that has two functions (F1 and F2), both returning a constant (0 and 1, respectively). These functions are "naughty" in that they write the fact they have been called to a table (T). First the simple code.
SQL> CREATE TABLE t( c1 VARCHAR2(30), c2 VARCHAR2(30) );
Table created.
SQL>
SQL> CREATE OR REPLACE PACKAGE pkg AS
  2     FUNCTION f1( p IN VARCHAR2 ) RETURN NUMBER;
  3     FUNCTION f2( p IN VARCHAR2 ) RETURN NUMBER;
  4  END pkg;
  5  /
Package created.
SQL>
SQL> CREATE OR REPLACE PACKAGE BODY pkg AS
  2 
  3     PROCEDURE ins( p1 IN VARCHAR2, p2 IN VARCHAR2 ) IS
  4        PRAGMA autonomous_transaction;
  5     BEGIN
  6        INSERT INTO t( c1, c2 ) VALUES( p1, p2 );
  7        COMMIT;
  8     END ins;
  9 
10     FUNCTION f1( p IN VARCHAR2 ) RETURN NUMBER IS
11     BEGIN
12        ins( p, 'F1' );
13        RETURN 0;
14     END f1;
15 
16     FUNCTION f2( p IN VARCHAR2 ) RETURN NUMBER IS
17     BEGIN
18        ins( p, 'F2' );
19        RETURN 1;
20     END f2;
21 
22  END pkg;
23  /
Package body created.Now to demonstrate how CASE and COALESCE short-circuits further evaluations whereas NVL doesn't, we can run a simple SQL statement and look at what we recorded in T after.
SQL> SELECT SUM(
  2           CASE
  3              WHEN pkg.f1('CASE') = 0
  4              OR   pkg.f2('CASE') = 1
  5              THEN 0
  6              ELSE 1
  7           END
  8           ) AS just_a_number_1
  9  ,      SUM(
10           NVL( pkg.f1('NVL'), pkg.f2('NVL') )
11           ) AS just_a_number_2
12  ,      SUM(
13           COALESCE(
14             pkg.f1('COALESCE'),
15             pkg.f2('COALESCE'))
16           ) AS just_a_number_3
17  FROM    user_objects;
JUST_A_NUMBER_1 JUST_A_NUMBER_2 JUST_A_NUMBER_3
              0               0               0
SQL>
SQL> SELECT c1, c2, count(*)
  2  FROM   t
  3  GROUP  BY
  4         c1, c2;
C1                             C2                               COUNT(*)
NVL                            F1                                     41
NVL                            F2                                     41
CASE                           F1                                     41
COALESCE                       F1                                     41We can see that NVL executes both functions even though the first parameter (F1) is never NULL. To see what happens in PL/SQL, I set up the following procedure. In 100 iterations of a loop, this will test both of your queries ( 1) IF ..OR.. and 2) bool := (... OR ...) ).
SQL> CREATE OR REPLACE PROCEDURE bool_order ( rc OUT SYS_REFCURSOR ) AS
  2 
  3     PROCEDURE take_a_bool( b IN BOOLEAN ) IS
  4     BEGIN
  5        NULL;
  6     END take_a_bool;
  7 
  8  BEGIN
  9 
10     FOR i IN 1 .. 100 LOOP
11 
12        IF pkg.f1('ANON_LOOP') = 0
13        OR pkg.f2('ANON_LOOP') = 1
14        THEN
15           take_a_bool(
16              pkg.f1('TAKE_A_BOOL') = 0 OR pkg.f2('TAKE_A_BOOL') = 1
17              );
18        END IF;
19 
20     END LOOP;
21 
22     OPEN rc FOR SELECT c1, c2, COUNT(*) AS c3
23                 FROM   t
24                 GROUP  BY
25                        c1, c2;
26 
27  END bool_order;
28  /
Procedure created.Now to test it...
SQL> TRUNCATE TABLE t;
Table truncated.
SQL>
SQL> var rc refcursor;
SQL> set autoprint on
SQL>
SQL> exec bool_order(:rc);
PL/SQL procedure successfully completed.
C1                             C2                                     C3
ANON_LOOP                      F1                                    100
TAKE_A_BOOL                    F1                                    100
SQL> ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=0;
Session altered.
SQL> exec bool_order(:rc);
PL/SQL procedure successfully completed.
C1                             C2                                     C3
ANON_LOOP                      F1                                    200
TAKE_A_BOOL                    F1                                    200The above shows that the short-circuiting occurs as documented, under the maximum and minimum optimisation levels ( 10g-specific ). The F2 function is never called. What we have NOT seen, however, is PL/SQL exploiting the freedom to re-order these expressions, presumably because on such a simple example, there is no clear benefit to doing so. And I can verify that switching the order of the calls to F1 and F2 around yields the results in favour of F2 as expected.
Regards
Adrian