Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can some one give me a small explanation about how and when should someone use sys_refcursor ?

share|improve this question
up vote 8 down vote accepted

A cursor is a pointer to a result set for a query. By returning a sys_refcursor you allow the client to fetch as many or few of the rows from the query as it requires. In stateful applications this could be used to page through results.

A cursor can allow more flexibility than writing a PL/SQL function that returns an array as it's completely up to the client how many rows to fetch and when to stop. That said, I've not found many cases where this additional flexibility is useful.

It's worth noting that the sys_refcursor is weakly typed, so you can return pointers to queries which not only have different from or where clauses, but different numbers and types of columns as well. Alternatively you can use strongly typed cursor where the columns in the result set are fixed.

This enables you to write functions which return different queries, like so:

create function get_data ( type varchar2 ) return sys_refcursor as
  ret_cur sys_refcursor;

  if type = 'EMP' then
    open ret_cur for select * from emp;
  elsif type = 'DEPT' then
    open ret_cur for select * from dept;
  end if;

  return ret_cur;

However, if you're using sys_refcursor to create a generic "open a query" function like the above you're probably doing something wrong!

share|improve this answer
Thanks a lot. . – Alejandro Bastidas Feb 5 '13 at 21:21
Awesome answer! – Phil Feb 5 '13 at 23:49

As an example of the possibilities: because it's pl/sql in back, one can define an object to represent a row, define a pl/sql table of those objects,

create type T_MY_TABLE as table of t_my_object;

and end with

OPEN p_recordset FOR select * from table( v_my_table );

So rather than constructing mongo, often dense and/or cryptic direct queries on a database table, one can create an internal table and have the whole power of pl/sql to populate it. And the client collecting the result-set is none the wiser. And changing the definition of the internal table is easier from a management pov than changing a database table.

Also when using report-generators like Jasper, you can push the SQL out of the report and into the database, and just call the procedure to get the recordset, leaving the report-side to focus on the formatting.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.