Little More Clarification
Muhammad Riaz Shahid, June 14, 2007 - 3:12 am UTC
So if i execute following SQL:
SELECT col1
FROM t
and another user executes the same SQL from his/her session, you mean to say in shared pool we will be having two queries and both the queries will be parsed (supposing table t refers to same table in both queries)?
regards,
June 14, 2007 - 7:45 am UTC
if the grants and all are the same and table T is in fact the same table T, there would not be. What I am saying is that invokers rights is just like running a pro*c program, a VB program, whatever - the sql is parsed as the user invoking it and that will tend to cause more SQL (by design) to be unshareable.
use invokers rights once in a very blue moon.
Blue Moon
Mike, June 14, 2007 - 9:43 am UTC
Alexander hte ok, April 24, 2008 - 9:47 am UTC
Hi Tom,
Is there any other way out there that a user can execute pl/sql with definer's rights WITHOUT having execute granted directly to the user?
I have an application with user b that executes packages in schema a. He only has roles granted, the grant to call the package is in the role.
We forgot to make the roles default so the app started to fail. But I don't understand why this works at all, it says everywhere roles are disabled under definer's rights?
I checked for other elevated privs, the user only has table and package grants through a role, and some table grants granted directly.
April 28, 2008 - 12:08 pm UTC
in definers rights, roles are disabled during the compilation phase of all compiled stored objects
when you compile a procedure, everything that procedure accesses must be granted to the DEFINER directly, not via a role.
in order to simply EXECUTE a procedure, you just need a grant - either directly to you or indirectly via a role.
to COMPILE an object and have that object reference "X", you need to have that privilege granted DIRECTLY to you.