Ref cursor to table convertor

Question

Hello.
I ask you a favor and I hope you could help me out.
I have a lot of legacy functions that return REF CURSOR.
I'd like to have a generic method that convert a cursor variable to something what I could query with SELECT statement.
select * from TABLE(mypkg.CONVERT(LEGACYFUNCTION()));
Here I give you an example how I can deal with the problem.
But It's easy to see that "mypkg" depends on "ordr" table.
I would like the "mypkg" to be unaware of "ordr" table - it must be generic.
A legacy function looks like this one:
CREATE OR REPLACE FUNCTION LEGACYFUNCTION RETURN SYS_REFCURSOR AS
c SYS_REFCURSOR;
begin
OPEN c FOR SELECT * from ordr;
return c;
end;
Here my package that converts REF CURSOR to something good:
CREATE OR REPLACE PACKAGE mypkg AS
TYPE TabTyp IS TABLE OF ordr%ROWTYPE;
FUNCTION CONVERT(c IN SYS_REFCURSOR) RETURN TabTyp PIPELINED;
end;
CREATE OR REPLACE PACKAGE BODY mypkg AS
FUNCTION CONVERT(c IN SYS_REFCURSOR) RETURN TabTyp PIPELINED AS
data ordr%ROWTYPE;
begin
LOOP
FETCH c INTO data;
PIPE ROW(data);
EXIT WHEN c%NOTFOUND;
END LOOP;
CLOSE c;
end;
end;
I'm looking for something like SELET * FROM CONVERT(LEGACYFUNCTION());
Thanks

Answer 1

> On Oracle 10.1 I can't even get compile:
CREATE OR REPLACE PACKAGE mypkg AS
FUNCTION CONVERT(c IN SYS_REFCURSOR) RETURN
SYS.ANYDATASET PIPELINED;
end;
It's work, but not for PIPELINED functions. I can't
generalize my first example.
Pipeline table functions can be generalised. In PL/SQL. Using the any data set type. It is possible.
BUT.. In this case it will be a major hack to make it work for you. I honestly think it is NOT the correct thing to do to solve your problem. Nor is it feasible with you proclaiming no Oracle experience as doing this, generically via a pipeline table, is not trivial coding.
> I'm java developer, thus I can't refactor Oracle
database.
Then you get an Oracle back-end developer that can. I harp almost everyday (in some forum on the net or in the office with our developers) that one fixes CAUSES and not symptoms.
The root cause you have is that the ref cursors returns data sets that you need to manipulate further - given your requirement that you want to run additional SQLs on the ref cursors.
Slapping any kind of interface layer over these ref cursors to as a "fix" does not address the cause. It is a fix that will not scale. A fix that is not robust. A fix that introduces more moving parts between the application and Oracle which means a bigger chance of failure.
So the choices you have seem simple. Either learn how to use Oracle and refactor the Oracle side - or get someone with the expertise do it.
I understand that is easy said. But these fact should not be ignored.
> I want to ask you a favor. Not write PL/SQL function
that return a REF CURSOR.
Er.. you missed me completely with that statement. Are you saying that a ref cursor pipeline is too complex or not doing the job? If so, then yes - I agree in principle that this is the wrong method for you to use to address your problem.