Re: unable to create stored outline for sql inside a procedure --

Shaleen

Def.Rights:
Roles can be enabled or disabled -- an unit must not be dependent on the enabled/disabled roles. There is nothing bad to have such design. This design is well thought, IMHO. At least at it's [was] consistent [on the moment of its invention].

Inv.right
Due to the context switching inv.right program units are a little bit (simplified) more expensive to be managed than def.rights. Such units require some more development efforts and accuracy (internal/external names).

 >>> 2) To take care of this problem invokers rights facility  >>> was introduced. Then why this restriction on roles.

The advantage is reusable and manageable code but not just the problem with roles. Def.rights units have their advantages too -- the biggest one, IMHO -- no 'context switching'. Stored Java stuff is also based on inv.right facility.

Kind regards,

-- 
Vladimir Begun
The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.

Shaleen wrote:


> Hmm. Makes sense. Thanks Tim.

> ----- Original Message -----

> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>

> Sent: Thursday, December 26, 2002 2:34 PM

> 

> 

> 

>>I don't agree that anyone "shirked".  Roles are, by design, changeable
>>within a session.  The SET ROLE command is not DDL, altering the metadata


> 

> of

> 

>>the database.  Instead, it is only altering already-granted permissions to
>>used subsequently by the session.  So, why should "permanent" objects


> 

> (such

> 

>>as views, procedure, packages, triggers, etc) be created using permissions
>>which are inherently transitory (i.e. available via roles)?  Just because
>>very few people use SET ROLE during a session doesn't alter its basic
>>properties...
>>
>>When that note says that "complexity would be raised to the Nth degree",
>>they are not necessarily indicating that Oracle could not have implemented
>>it.  This stuff is simplicity itself compared to the


> 

> transaction-consistency

> 

>>model.  Rather, the complexity would have been on the database
>>administration side (not in the database engine), and a major pain in
>>everyone's behind.  Think it through.  Oracle made a good design decision


> 

> to

> 

>>prevent unnecessary complexity in database administration.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Vladimir Begun
  INET: vladimir.begun_at_oracle.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).