This article covers how to write PL/SQL object table functions. PL/SQL object table functions provide you with a powerful technique to solve complex query problems. You can use object table functions to return result sets that you can’t write as a query.

There is just one caveat on using object table functions. You must truly require complex logic that can’t be resolved in an ordinary query. For reference, this example really doesn’t need to be an object table function but it demonstrates tips and techniques related to them.

This article teaches you how to do the following:

  • Create an object type and collection
  • Create an object table function
  • Create co-dependent cursors and merge co-dependent cursors
  • Use native dynamic SQL (NDS) to query a result set of unknown values
  • Use bulk collection to populate a collection of object types
  • Construct instances and a collection of instances in a SELECT-list clause

You can access the results of a PL/SQL object table function from an ordinary query when you leverage Oracle’s built-in TABLE function. This means you can handle the results like columns from any table or view.

A PL/SQL object table function returns a collection of a SQL object type. A SQL object type can be simple or complex. A simple object type lists a record. A record, sometimes called a struct, is a collection of fields. As a rule, the fields of a record often have different scalar data types, like the definition of a table. The fields of a record are often called members to avoid confusing them with elements of a collection.

A complex SQL object type includes member methods. Complex SQL object types require special handling but object table functions return simple SQL object types.

While you can create a table with a CREATE TABLE statement, you create a collection of a SQL object type in two steps. Step one creates the SQL object type. Step two creates the SQL collection.

To build the PL/SQL object table function, you need to create the object type and the collection of the object type first. The following statement creates the table_struct object type:

  2    TYPE table_struct IS OBJECT
  3    ( table_name    VARCHAR2(30)
  4    , column_cnt    NUMBER
  5    , avg_col_len   NUMBER
  6    , row_cnt       NUMBER
  7    , avg_row_len   NUMBER
  8    , chain_cnt     NUMBER );
  9  /

The table_struct example separates the CREATE OR REPLACE syntax on line 1 from the object type definition on lines 2 through 8. That’s done to highlight the importance of the semicolon on line 8. The semicolon is a statement terminator. You need a statement terminator because the object type definition is a PL/SQL statement. After the PL/SQL statement, you need a forward slash on line 9 to execute the statement.

After you create the the table_struct object type, you create the table_list collection with the following statement:

  2    TYPE table_list IS TABLE OF table_struct;
  3  /

Having defined the object type and collection, you can now create an object type function. The difference between an ordinary function and an object type function is the return type. Ordinary functions return scalar data types. Pipelined table functions return a SQL result set in place of a PL/SQL record collection. Object table functions return a SQL collection. The difference between a pipelined table function and object table function is straightforward.

A pipelined table function converts a PL/SQL collection of a PL/SQL record type (another type of record structure) or an embedded SQL object type into an aggregate result set. You write pipelined table functions when working with legacy PL/SQL collections.

An object type function returns a SQL collection. SQL collections are aggregate result sets by default. This makes type casting the only difference between pipelined and object table functions. The SQL built-in TABLE function manages the result from the pipelined and object table functions the same way.

The listing function shows you how to write an object table function. The listing function returns a composite view of data dictionary values and the dynamic count of rows from physical tables. It uses explicit cursors and Native Dynamic SQL to create a dynamic data set, which you can return by a simple query.

You have two options when you define any PL/SQL function – a row-by-row or bulk processing. This article explores both because it is often easier for some developers to see the row-by-row approach before they explore the bulk processing option. As a rule, the bulk processing approach is always the more efficient solution.

The row-by-row version of the listing program is:

2 FUNCTION listing RETURN table_list IS
  3    /* Variable list. */
  4    lv_column_cnt   NUMBER;
  5    lv_avg_col_len  NUMBER;
  6    lv_row_cnt     NUMBER;
  8    /* Declare a statement variable. */
  9    stmt VARCHAR2(200);
 11    /* Declare a system reference cursor variable. */
 12    lv_refcursor SYS_REFCURSOR;
 13    lv_table_cnt NUMBER;
 15    /* Declare an output variable. */
 16    lv_list  TABLE_LIST := table_list();
 18    /* Declare a table list cursor. */
 19    CURSOR c IS
 20      SELECT table_name
 21      ,    avg_row_len
 22      ,    chain_cnt
 23      FROM   user_tables
 24      WHERE  table_name NOT IN
 25            ('DEPT','EMP','APEX$_ACL','APEX$_WS_WEBPG_SECTIONS'
 27            ,'APEX$_WS_LINKS','APEX$_WS_TAGS','APEX$_WS_FILES'
 30            ,'DEMO_ORDER_ITEMS','DEMO_STATES');
 32    /* Declare a column count. */
 33    CURSOR column_cnt
 34    ( cv_table_name  VARCHAR2 ) IS
 35      SELECT COUNT(column_id) AS cnt_columns
 36      ,      SUM(avg_col_len)/COUNT(column_id) AS avg_col_len
 37      FROM     user_tab_columns
 38      WHERE    table_name = cv_table_name;
 39  BEGIN
 40    /* Read through the data set of non-environment variables. */
 41    FOR i IN c LOOP
 42      /* Count the columns of a table. */
 43      FOR j IN column_cnt(i.table_name) LOOP
 44        lv_column_cnt := j.cnt_columns;
 45        lv_avg_col_len := j.avg_col_len;
 46      END LOOP;
 48      /* Declare a statement. */
 49      stmt := 'SELECT COUNT(*) AS column_cnt FROM '||i.table_name;
 51      /* Open the cursor and write set to collection. */
 52      OPEN lv_refcursor FOR stmt;
 53      LOOP
 54        FETCH lv_refcursor INTO lv_table_cnt;
 55        EXIT WHEN lv_refcursor%NOTFOUND;
 56        lv_list.EXTEND;
 57        lv_list(lv_list.COUNT) := table_struct(
 58                                 table_name  => i.table_name
 59                               , avg_row_len => i.avg_row_len
 60                                , chain_cnt   => i.chain_cnt
 61                                , column_cnt  => lv_column_cnt
 62                                , avg_col_len => lv_avg_col_len
 63                                 , row_cnt     => lv_table_cnt);
 64      END LOOP;
 65    END LOOP;
 66    /* Return the collection. */
 67    RETURN lv_list;
 68  END;
 69  /

Line 2 returns the table_list collection. Lines 9, 12, and 13 support the NDS statement in the listing function. Line 16 creates an empty table_list collection by declaring the variable and instantiating an empty collection.

The column_cnt cursor is a parameterized cursor, and the SELECT-list on lines 35 and 36 calculates statistics for each table processed in the nested for loop on lines 43 thru 46.

The column_cnt cursor and nested loop are examples of poor coding technique. A simple join between the user_tables and user_tab_columns views eliminates both. While the row-by-row mechanic doesn’t highlight this type of inefficiency, the bulk processing approach does.

Line 49 uses concatenation because NDS doesn’t let you bind table names. Line 52 opens a PL/SQL reference cursor for the dynamic statement. Line 54 fetches each row into a scalar variable. Line 55 exits the dynamic reference cursor when all rows have been read. Line 56 extends the memory of the lv_list collection and line 57 assigns an instance of the table_struct object type as an element of the collection. Line 67 returns the lv_list collection.

The NDS element is also a poor coding technique because the num_rows column in the user_tables view holds the number of rows in any table. While the num_rows column is dependent on running statistics, most databases enable statistics as a background process. You should only use NDS when you truly need to do so.

You can query the result and format the results in SQL*Plus or simply run the following query in SQL*Developer or Toad:

  2  FROM   TABLE(listing);

Line 1 uses the asterisk to return all columns in the SELECT-list. Line 2 uses the TABLE built-in function to convert the collection to a SQL result set. The program would print something like the following in SQL*Plus with appropriate formatting:

                                 Column    Row  Chain
Table Name           Column #    Length Length  Count  Row #
-------------------- -------- --------- ------ ------ ------
                       14     14.21    197      0     93
SYSTEM_USER                11      4.36     48      0      5
ACCOUNT_LIST                8      5.13     38      0    200
RENTAL_ITEM                 9      4.56     41      0  4,703
STREET_ADDRESS              8      6.50     52      0     28
CALENDAR                    9      6.00     53      0    300
TELEPHONE                  11      5.00     55      0     18
AIRPORT                     9      6.89     61      0      6
CONTACT                    10      5.30     51      0     18
TRANSACTION                12      6.58     79      0  4,694
ADDRESS                    10      5.60     55      0     18
MEMBER                      9      7.22     65      0     10
PRICE                      11      4.36     48      0    558
RENTAL                      8      5.75     46      0  4,694
COMMON_LOOKUP              10     10.30    101      0     49

15 rows selected.

The refactored listing object table function uses bulk processing. As a result of the change, you remove the column_cnt cursor by joining the user_tables and user_tab_columns views. You also add the num_rows column to your base cursor.

The following creates the refactored listing object table function:

  2  FUNCTION listing RETURN table_list IS
  3    /* Variable list. */
  4    lv_column_cnt   NUMBER;
  5    lv_avg_col_len  NUMBER;
  6    lv_row_cnt         NUMBER;
  8    /* Declare a statement variable. */
  9    stmt     VARCHAR2(200);
 11    /* Declare a system reference cursor variable. */
 12    lv_refcursor     SYS_REFCURSOR;
 13    lv_table_cnt     NUMBER;
 15    /* Declare an output variable. */
 16    lv_list  TABLE_LIST;
 18    /* Declare a table list cursor. */
 19    CURSOR c IS
 20    SELECT  table_struct(
 21        table_name => ut.table_name
 22      , column_cnt => COUNT(utc.column_id)
 23      , avg_col_len =>SUM(avg_col_len)/COUNT(column_id)
 24      , avg_row_len => ut.avg_row_len
 25      , chain_cnt => ut.chain_cnt
 26      , row_cnt => num_rows )
 27    FROM    user_tables ut INNER JOIN user_tab_columns utc
 28    ON      ut.table_name = utc.table_name
 29    WHERE   ut.table_name NOT IN
 30            ('DEPT','EMP','APEX$_ACL','APEX$_WS_WEBPG_SECTIONS'
 31             ,'APEX$_WS_ROWS','APEX$_WS_HISTORY','APEX$_WS_NOTES'
 32            ,'APEX$_WS_LINKS','APEX$_WS_TAGS','APEX$_WS_FILES'
 35               ,'DEMO_ORDER_ITEMS','DEMO_STATES')
 36      GROUP BY ut.table_name
 37      ,        ut.avg_row_len
 38      ,        ut.chain_cnt
 39      ,        ut.num_rows;
 41  BEGIN
 42    /* Read set into collection. */
 43    OPEN     c;
 44    FETCH c BULK COLLECT INTO lv_list;
 45    CLOSE c;
 47    /* Return the collection. */
 48    RETURN lv_list;
 49  END;
 50  /

Line 16 no longer initializes the lv_list collection because the BULK COLLECT assigns a complete collation to the variable. The BULK COLLECT effectively manages the memory allocation because you embed the constructor logic in the SELECT-list of the cursor on lines 20 thru 26.

The new cursor includes a join between the user_tables and user_tab_columns views. It also includes reference to the num_rows column of the user_tables view. This effectively means a single bulk cursor returns everything that’s needed in the listing object table function. Line 43 opens the cursor, line 44 fetches all the rows into a collection, and line 45 closes the cursor. Line 48 returns the collection of the object type.

The reality is that simple examples like this demonstrate tips and techniques but may not really benefit from those features. While you have learned the tips and techniques to write and leverage object table functions, don’t write them unless they add value to your solution space.