Returning rows from stored proc

Question

Hello, this is the sample from the SQL Developer help to create proc:
CREATE OR REPLACE
PROCEDURE list_a_rating(in_rating IN NUMBER) AS
matching_title VARCHAR2(50);
TYPE my_cursor IS REF CURSOR;
the_cursor my_cursor;
BEGIN
OPEN the_cursor
FOR 'SELECT title
FROM books
WHERE rating = :in_rating'
USING in_rating;
DBMS_OUTPUT.PUT_LINE('All books with a rating of ' || in_rating || ':');
LOOP
FETCH the_cursor INTO matching_title;
EXIT WHEN the_cursor%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(matching_title);
END LOOP;
CLOSE the_cursor;
END list_a_rating;
You have to write a cursor just to display results from a query. To me this is whacked but I'll go with it. So what if you wanted to return that resultset or refcursor so it can be consumed by a calling application or procedure? I tried something like
CREATE OR REPLACE PROCEDURE list_a_rating(in_rating IN NUMBER, MatchingTitles OUT Ref Cursor)
but that's not compiling. How do you return data from a proc or function?
Thanks,
Ken

Answer 1

ktrock wrote:
Hello, this is the sample from the SQL Developer help to create proc:A very poor example..
You have to write a cursor just to display results from a query. To me this is whacked but I'll go with it. All SQL you send to Oracle for parsing and execution winds up as SQL cursors in the server's SQL shared pool. You, the client, then get a handle as reference to this cursor that was created for your SQL statement. Using this handle you can now fetch the output of the cursor and consume it on the client side.
So there is no such thing as not using a cursor - you always use cursors. Many times it will be implicitly as you won't see the cursor workings as the client hides that from you.
As for DBMS_OUTPUT and PL/SQL... PL/SQL cannot "write output". And time and again (stupid?) people will use DBMS_OUTPUT thinking that is "writing to the client's display device".
It is not. It is writing data into a PL/SQL variable on the server. PL/SQL variable that consumes very expensive dedicated process memory on the server. The client (SQL-Developer, TOAD, SQL*Plus, etc) can read the contents of this variable and the client can render that contents on the client's display device.
So how on earth does it make sense to take SQL data on the server (that is structured data and can vary significantly in volume), and write that as plain text into a PL/SQL variable?
It does not make sense. At all. Bluntly put - it is just plain bloody stupid.
So how do you return data using PL/SQL? The same way as you return data using SQL.
PL/SQL allows the complexity of the SQL language, database model and so on to be moved from the client application into PL/SQL itself. The client thus no longer need to know table names, what to join where and when, how to write effective SQL and so on. It calls a PL/SQL procedure with optional parameters. This procedure has the logic to create the required SQL (based on the parameters too if applicable) and return the cursor handle for that SQL.
The client thus calls PL/SQL, PL/SQL serves as the SQL abstraction layer and does the complex SQL bit, and PL/SQL then returns the SQL cursor handle to the client.
In the PL/SQL language, there are different data types for dealing with the same SQL cursor handle - depending on what you want to do with that SQL cursor.
If you want to pass that SQL cursor handle to a client, then you need to use the sys_refcursor data type in PL/SQL. Remember that SQL cursor does not know or care what data type the client (such as PL/SQL) uses to reference it. All SQL cursors in the server's shared pool are the same - how you treat them from a client side (as an explicit cursor, implicit cursor, ref cursor, etc) is a client program decision.
Also keep in mind that a SQL cursor is NOT a result set. It is not a data set that is instantiated or created on the server that contains the data (or references to the data) for your SQL.
If this was the case - just how many such cursor result sets could the server create before running out of memory?
A cursor is an executable program. The source SQL code is compiled into a program called a cursor. This cursor contains the execution steps that the server needs to follow to find the data. The cursor then outputs this data as data is found. The execution plan of a cursor shows how this program looks like.