The introduction
This is showing the difference between definer and invoker rights in terms of current user and current schema – what context is the code running in.

The setup
In schema JOHN create two stored procedures one with definer rights the other with invoker rights both printing the same SYS_CONTEXT parameters.

SQL> create or replace procedure print_user_info_def
is
begin
  dbms_output.put_line('USER: '||user);
  dbms_output.put_line('SESSION_USER: '||sys_context('userenv', 'session_user'));
  dbms_output.put_line('CURRENT_USER: '||sys_context('userenv', 'current_user'));
  dbms_output.put_line('CURRENT_SCHEMA: '||sys_context('userenv', 'current_schema'));
end print_user_info_def;
/

SQL> create or replace procedure print_user_info_inv
authid current_user
is
begin
  dbms_output.put_line('USER: '||user);
  dbms_output.put_line('SESSION_USER: '||sys_context('userenv', 'session_user'));
  dbms_output.put_line('CURRENT_USER: '||sys_context('userenv', 'current_user'));
  dbms_output.put_line('CURRENT_SCHEMA: '||sys_context('userenv', 'current_schema'));
end print_user_info_inv;
/

The result
Log-in with user JANE and run the two stored procedures owned by JOHN

SQL> exec john.print_user_info_def
USER: JANE
SESSION_USER: JANE
CURRENT_USER: JOHN
CURRENT_SCHEMA: JOHN

SQL> exec john.print_user_info_inv
USER: JANE
SESSION_USER: JANE
CURRENT_USER: JANE
CURRENT_SCHEMA: JANE

Foot note: All tests have been run on a 10g 10.2.0.4 database.

Although behind the scenes Oracle will perform a “select .nextval from dual” and therefore really doesn’t improve performance or anything I’m looking forward to write 11g PL/SQL code where you can use the sequence pseudo-columns CURRVAL and NEXTVAL in expressions. First off, I always prefer to use the .NEXTVAL in the SQL statement itself and use the RETURNING INTO clause to assign the new value to a PL/SQL variable. BUT, if the case requires for some reason to get the sequence value in PL/SQL without going through a SQL statement first just imagine how beautiful and elegant your code will look like without having “select .netxval into from dual;” spread all over the place…

SQL> create sequence seq;

-- the 10g and prior way
SQL> declare
  nextval number;
begin
  select seq.nextval
  into nextval
  from dual;
end;
/

-- the 11g way
SQL> declare
  nextval number;
begin
  nextval := seq.nextval;
end;
/

You can basically use the sequence pseudo-columns everywhere where a number value is valid in the expression, e.g. “…if seq.currval > 10 then…”

Have you ever looked at a big long package/procedure and wondered what the scope of a variable might be in this web of nested named and unnamed PL/SQL blocks? I’m sure all of you have.
There are a few naming convention proposals out there that suggest using prefixes like “l_” for local, “g_” for global variables, etc which is some kind of Systems Hungarian notation (I’m not convinced of the usefulness of System Hungarian whereas I can see some benefit of App Hungarian if properly applied on the variable scope – read more about it at Joel’s).
The problem rises when there are multiple nested blocks, what’s now the scope of this “l_” prefixed variable again? You simply don’t know until you back track it to the declaration of that variable.
That’s where qualified names come in pretty handy, let’s examine:

create or replace package pck
as
  procedure p1 (
     text in varchar2
  );
end pck;
/

create or replace package body pck
as
  text varchar2(10);
 
  procedure p1 (
     text in varchar2
  )
  is
  begin
    pck.text := p1.text;
  end p1;
end pck;
/

Note that in procedure P1 we use qualifiers for the variable and parameter TEXT. Even though they have the same name, the scope is very clear. We could even qualify the parameter with the package name which would make it a bit long, e.g. “pck.text := pck.p1.text;”
Isn’t this beautiful? Absolutely, but as soon as we use long package, procedure and variable names it can make the code somewhat cumbersome to read as you end up with very long expressions. In my opinion I think the benefits of qualified names far outweigh the disadvantages of having a bit longer code lines – you can look at one (maybe big) line of code and you have all the information, no need for scrolling up to the declaration to find out the scope.