For example, imagine I have a package. That package contains a function that accepts arguments, builds a dynamic SELECT and stores the results of that SELECT in a REF CURSOR.

This is where the problem starts. I now want to pipeline the REF CURSOR rows. Using the REF CURSOR as the function output, and doing a TABLE(function) on it doesn’t work – as you showed in your article.

So I thought, why not dynamically build a new type (DYNTYPE) on the basis of your REF CURSOR metadata inside your package. This could happen inside an extra procedure which you call at the end of your first function.

You would then write an extra function that accepts the REF CURSOR as input and pipelines a TABLE OF DYNTYPE, and we’re done.

But the question is – how do you create a type on the basis of REF CURSOR metadata inside a package?

And if this approach doesn’t work, can you make any other suggestion for pipelining when the number and types of underlying columns of your REF CURSOR is unknown at design time?

This would be a very flexible tool.

(In my case it’s actually the only way to go because my client application (S-Plus) will only receive data if you hard-code a SQL statemtent or if you pipeline a table function back to it.)

I’d suggest if you query the possible number of row returns before querying the data. When the number or rows exceeds a reasonable set, prompt the end-user with the opportunity to download a CSV file. If they say yes, then use the LIMIT syntax like this to write blocks of rows that fit within your allocate SGA memory constraints. I’d recommend an external table because you can perform bulk writes. Make sure you set up the external table with SQL*Loader not Data Pump. You could also use a Java program to write it to a non-Oracle owned directory with something like this blog post.

OPEN c;
LOOP
  FETCH c BULK COLLECT INTO record_type LIMIT 1000;
  EXIT WHEN record_type.COUNT = 0;
  FOR i IN 1..record_type.COUNT LOOP
    ... WRITE logic ...
  END LOOP;
END LOOP;

Since you’re in Java it might be more effective to simply write the data streams to the middle-tier. I hope this helps but if I misunderstood let me know.

Oracle view -> Oracle package/pipelined table function -> Oracle java -> Source system web service

Works great and fast when I issue ’select * from view where id = 1′. The problem is I cannot prevent an individual or a software tool from issuing ’select * from view’. Without the where clause the table function will bog down my database and network trying to pull back hundreds of millions of rows. I cannot try to artificially scale back the table function’s incoming ref cursor using rownum because someone could ask the legit question ’select * from view where month = 1′ and get back an incomplete set of data. Any advise or experience in this regard that you could offer me?