I suspect one won't have any choice. At least it's well formatted -- all the types begin with TYPE, and so on.
You could use SQL*Plus and the DESC
command, which does work on packages:
SQL> desc dbms_application_info;
PROCEDURE READ_CLIENT_INFO
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
CLIENT_INFO VARCHAR2 OUT
PROCEDURE READ_MODULE
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
MODULE_NAME VARCHAR2 OUT
ACTION_NAME VARCHAR2 OUT
PROCEDURE SET_ACTION
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
ACTION_NAME VARCHAR2 IN
PROCEDURE SET_CLIENT_INFO
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
CLIENT_INFO VARCHAR2 IN
PROCEDURE SET_MODULE
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
MODULE_NAME VARCHAR2 IN
ACTION_NAME VARCHAR2 IN
PROCEDURE SET_SESSION_LONGOPS
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
RINDEX BINARY_INTEGER IN/OUT
SLNO BINARY_INTEGER IN/OUT
OP_NAME VARCHAR2 IN DEFAULT
TARGET BINARY_INTEGER IN DEFAULT
CONTEXT BINARY_INTEGER IN DEFAULT
SOFAR NUMBER IN DEFAULT
TOTALWORK NUMBER IN DEFAULT
TARGET_DESC VARCHAR2 IN DEFAULT
UNITS VARCHAR2 IN DEFAULT
By iterating over the packages, and parsing the results -- it's an easier structure to parse than DBA_SOURCE -- you might get what you want. A caveat to remember; packages support overloading so you could have both FUNCTION foo(date) RETURN date
, and PROCEDURE foo(varchar)
. Matching just by name may not be enough.