Parsing package authorization

If a colleague reports a case, he or she wants to add permissions such as viewing, executing, debugging, replacing, and debugging the package. Next I sorted out what permissions can be done.
First, we have the following three dimensions for this type of authorization: Header, package view, execution, compilation, replacement, and debug: permission for a certain package, or permission for all packages. 1. view the permission grant create any procedure to fwy3; literally, it is the permission to create any procedure. However, in addition to the creation process, you can also view the code of any package header package. Permission to view, execute, compile, and replace data. 2. Execution permission grant execute any procedure to fwy3; grant execute on scott. package_1 to fwy; grant execution permission. You can see that the header does not see the package body. It can be executed, cannot be compiled, and cannot be replaced. 3. grant alter any procedure to fwy3; at this time, the user has the compilation permission to compile any procedure, function, package and package body, such as alter procedure New_procedure compile; alter function New_function compile; alater package package_name compile [package | body]; you are not authorized to view, execute, compile, or replace the package. The compilation permission can only be compiled based on the original code, rather than the new code. 4. Replace permissions when viewing and compiling permissions are combined, that is, when both the 1st and 3rd points are available, you can replace the permissions. The replacement is to compile and view it. 5. debug permission. Grant debug any procedure to fwy3; -- system permission grant debug on dbmgr. PKG_AUDIT_RULE to fwy; -- grant the object permission debug connect session to fwy3; -- if the system permission is used by the plsql developer tool, you must click the object mail-add debugging information to debug.