Look at the example, it was from 7.3.4 (see my prompt, I always have the version in it).

I did it in 7.3.4 and 8.0 in order to help narrow down where pragma violations where happening.  Consider:

ops$ora734@ORA734.WORLD> create or replace package my_pkg
  2  as
  3      function foo return number;
  4      pragma restrict_references( foo, wnds, rnds, wnps, rnps );
  5  end;
  6  /

Package created.

ops$ora734@ORA734.WORLD> 
ops$ora734@ORA734.WORLD> create or replace package body my_pkg
  2  as
  3  
  3  function foo return number
  4  is
  5  begin
  6      return 0;
  7  end;
  8  
  8  
  8  begin
  9      update emp set ename = ename;
 10  end;
 11  /

Warning: Package Body created with compilation errors.

ops$ora734@ORA734.WORLD> show err
Errors for PACKAGE BODY MY_PKG:

LINE/COL ERROR
-------- -----------------------------------------------------------------
0/0      PL/SQL: Compilation unit analysis terminated
3/1      PLS-00452: Subprogram 'FOO' violates its associated pragma

<b>obviously FOO itself doesn't violate its pragma -- it doesn't do anything.  So whats the problem?  Add the other pragma</b>


ops$ora734@ORA734.WORLD> create or replace package my_pkg
  2  as
  3      pragma restrict_references( my_pkg, wnds, rnds, wnps, rnps );
  4  
  4      function foo return number;
  5      pragma restrict_references( foo, wnds, rnds, wnps, rnps );
  6  
  6  end;
  7  /

Package created.

ops$ora734@ORA734.WORLD> 
ops$ora734@ORA734.WORLD> create or replace package body my_pkg
  2  as
  3  
  3  function foo return number
  4  is
  5  begin
  6      return 0;
  7  end;
  8  
  8  
  8  begin
  9      update emp set ename = ename;
 10  end;
 11  /

Warning: Package Body created with compilation errors.

ops$ora734@ORA734.WORLD> show err
Errors for PACKAGE BODY MY_PKG:

LINE/COL ERROR
-------- -----------------------------------------------------------------
0/0      PL/SQL: Compilation unit analysis terminated
3/5      PLS-00452: Subprogram 'MY_PKG' violates its associated pragma

Ahh, now its a tad more clear where the error is.  I just did it as a matter of habit to help me track down where the pragma was really being violated. 

1) a pragma is a compiler directive.  It alters the default behavior of the compiler.

Normally the compiler really, honestly just doesn't care if we update the database in our procedures.  It doesn't care.  However, if I ASSERT via the pragma restrict_references that my code DOESN'T update the database (via WNDS) and the compiler catches me lying to it (it sees that I do in fact have the ability to update the database in my procedure), it'll fail the compilation.  

Hence, when you assert the purity level, you're asking the compiler to verify that for you.

Without the pragma in versions 7.x and 8.0, you would not be able to invoked packaged procedures from SQL -- thats the "helpful" part of them.  They allow packaged procedures to be called from sql.

2) see 1

3) In 8i we made is so you did not have to SPECIFY the purity level (we compute it a compile time).  

ops$tkyte@ORA817DEV.US.ORACLE.COM> create or replace function foo return number
  2  as
  3  begin
  4     update emp set ename = ename;
  5      return sql%rowcount;
  6  end;
  7  /

Function created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> select foo from dual;
select foo from dual
       *
ERROR at line 1:
ORA-14551: cannot perform a DML operation inside a query
ORA-06512: at "OPS$TKYTE.FOO", line 4
ORA-06512: at line 1

you still cannot do that UNLESS the function is an autonomous transaction (and even then -- you had better be really really smart about what you are doing).

The reason this is BAD is easily demonstrated:

ops$tkyte@ORA817DEV.US.ORACLE.COM> create table t as select * from all_users where rownum <= 10;

Table created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> create table cnt ( x int );
Table created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> insert into cnt values (0);
1 row created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> create or replace function foo return number
  2  as
  3          pragma autonomous_transaction;
  4          l_x number;
  5  begin
  6          update cnt set x = x+1 returning x into l_x;
  7          commit;
  8  
  9          return l_x;
 10  end;
 11  /
Function created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace on explain
ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from t where user_id = foo;

no rows selected


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'T'



ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace off

ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from cnt;

         X
----------
        10

<b>no surprises there -- 10 rows, cnt = 10, seems OK right.  Seems predicable right.  No, not really:</b>

ops$tkyte@ORA817DEV.US.ORACLE.COM> create index t_idx on t(user_id);
Index created.

ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace on explain
ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from t where user_id = foo;

no rows selected


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T'
   2    1     INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE)



ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace off

ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from cnt;

         X
----------
        12

<b>Now we did it 2 times for that query.  Why two?  I don't know, I don't really care (truly not our business, they just called it two times to do the index processing).  No, the result is not deterministic.  What if the optimizer decides to change the plan again later?</b>

ops$tkyte@ORA817DEV.US.ORACLE.COM> analyze table t compute statistics;

Table analyzed.

ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace on explain
ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from t where user_id = foo;

USERNAME                          USER_ID CREATED
------------------------------ ---------- ---------
DBSNMP                                 16 28-AUG-01


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=16)
   1    0   TABLE ACCESS (FULL) OF 'T' (Cost=1 Card=1 Bytes=16)



ops$tkyte@ORA817DEV.US.ORACLE.COM> set autotrace off
ops$tkyte@ORA817DEV.US.ORACLE.COM> select * from cnt;

         X
----------
        22

<b>Which is is free to do.  This is why calling functions from sql that have side effects is typically a really truly BAD IDEA. </b>

5) yes. we mean that.

6) 

Look at the spec:

ops$ora734@ORA734.WORLD> create or replace package my_pkg
  2  as<b>
  3      pragma restrict_references( my_pkg, wnds, rnds, wnps, rnps );
  4  </b>

I asserted that this package WNDS -- it writes no database state.  Now, look at the body:

ops$ora734@ORA734.WORLD> create or replace package body my_pkg
  2  as
  3  
  3  function foo return number
  4  is
  5  begin
  6      return 0;
  7  end;
  8  
  8  <b>
  8  begin
  9      update emp set ename = ename;
 10  end;</b>

 11  /

the elaboration code for this package DOES write the database state obviously.  I lied, the compiler caught me.  A more subtle way for the package itself to write the database state would be something like:

create or replace package my_pkg
as
     x number default foo;
      ......
end;

here foo is a function, foo updates the database, hence the package my_pkg updates the data, hence EVERY function in my_pkg updates the database, hence no function in my_pkg can be called from SQL. 

If you have my book -- i describe in painstaking detail how dbms_output works (so you'll fully understand why with DBMS_OUTPUT the answer is "no, you cannot").

You can use UTL_FILE and fopen in append/ put a line/ fclose and "tail -f" the file.

You can use dbms_application_info.set_session_longops to report progress in real time via a v$ view.

In 9i, you can use a pipelined function:

ps$tkyte@ORA920.LOCALHOST> create or replace type myScalarType as object
  2  ( dt timestamp, msg varchar(40) )
  3  /

Type created.

ops$tkyte@ORA920.LOCALHOST>
ops$tkyte@ORA920.LOCALHOST> create or replace type myTableType as table of myScalarType
  2  /

Type created.

ops$tkyte@ORA920.LOCALHOST>
ops$tkyte@ORA920.LOCALHOST> create or replace function virtual_table( p_num_rows in number )
  2  return myTableType
  3  PIPELINED    -- NOTE the pipelined keyword
  4  is
  5  begin
  6          pipe row( myScalarType( systimestamp, 'Starting...' ) );
  7      for i in 1 .. p_num_rows
  8      loop
  9                  pipe row( myScalarType( systimestamp, 'processing row ' || i ) );
 10                  dbms_lock.sleep( 1 );
 11      end loop;
 12
 13      return; -- note return with no value!
 14  end;
 15  /

Function created.

ops$tkyte@ORA920.LOCALHOST>
ops$tkyte@ORA920.LOCALHOST> set arraysize 1
ops$tkyte@ORA920.LOCALHOST> select * from TABLE( virtual_table(5) );

DT
---------------------------------------------------------------------------
MSG
----------------------------------------
18-SEP-02 06.55.52.238409 AM
Starting...

18-SEP-02 06.55.52.242138 AM
processing row 1

18-SEP-02 06.55.53.260283 AM
processing row 2

18-SEP-02 06.55.54.280308 AM
processing row 3

18-SEP-02 06.55.55.300272 AM
processing row 4

18-SEP-02 06.55.56.320289 AM
processing row 5


6 rows selected.


you cannot see it here -- but those rows appeared on my screen as they were produced -- I saw the first row long before the last. 

ops$tkyte%ORA9IR2> create or replace context my_global_ctx using my_proc accessed globally
  2  /

Context created.

ops$tkyte%ORA9IR2>
ops$tkyte%ORA9IR2> create or replace procedure my_proc( p_name in varchar2, p_val in varchar2 default null )
  2  as
  3  begin
  4      if (p_val is not null)
  5      then
  6          dbms_session.set_context( 'my_global_ctx', p_name, p_val );
  7      else
  8          dbms_session.clear_context( 'my_global_ctx', null );
  9      end if;
 10  end;
 11  /

Procedure created.

ops$tkyte%ORA9IR2>
ops$tkyte%ORA9IR2> exec dbms_output.put_line( 'debug = ' || sys_context( 'my_global_ctx', 'debug' ) );
debug =

PL/SQL procedure successfully completed.

ops$tkyte%ORA9IR2> set echo off
in another session execute
exec my_proc( 'debug', 'yeah' )
ops$tkyte%ORA9IR2> pause

ops$tkyte%ORA9IR2>
ops$tkyte%ORA9IR2> exec dbms_output.put_line( 'debug = ' || sys_context( 'my_global_ctx', 'debug' ) );
debug = yeah

PL/SQL procedure successfully completed.

ops$tkyte%ORA9IR2> set echo off
in another session execute
exec my_proc( 'debug' )
ops$tkyte%ORA9IR2> pause

ops$tkyte%ORA9IR2>
ops$tkyte%ORA9IR2> exec dbms_output.put_line( 'debug = ' || sys_context( 'my_global_ctx', 'debug' ) );
debug =

PL/SQL procedure successfully completed.