Function returning string. Data type question

Question

Hello all,
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
Our database has a parent record master_member_record_id & and children of those records member_record_id. I wrote a function which returns the master record for the child.
eg. get_master(member_record_id). simple enough.
I have wrote the opposite of this also, get_member_records(master_member_record_id). Obviously this function has multiple records to return so I have it set to return a listagg string with ',' separation. They want to be able to use this function as follows:
select * from member_table where member_record_id in (get_member_records(master_member_record_id));
or something similar, I realize this is a data type issue here, wondering if this is even possible. What do you think?
Thanks in advance for your criticism/help,
Chris

Answer 1

My disagreement is with how pipeline table functionality is used.
Instead of this (what it sounds like the OP is doing but returning CSV format)
create or replace type TClientIdArray is table of number;
create or replace function GetClientIDs( parentID number ) return TClientIdArray is
  array TClientIdArray;
begin
  select
    client_id bulk collect into array
  from master_table
  where parent_id = parentID;
  return( array );
end;A pipeline would look as follows:
create or replace type TClientIdArray is table of number;
create or replace function GetClientIDs( parentID number ) return TClientIdArray pipelined is
begin
  for c in (select
               client_id
             from master_table
             where parent_id = parentID ) loop
    pipe row( c.client_id );
  end loop;
  return;
end;The first method is in fact more sensible in this case, especially when used from PL/SQL. A single SQL call/context switch to get a list of client identifiers. The issues with the first method are
- cannot effectively deal with a large data set of client identifiers
- would be suboptimal to use this function in subsequent SQL
- if called by a client, a ref cursor (not collection) should be returned
But assuming that the list of client identifiers are needed to be stepped through via complex PL/SQL app processing, using a (small) array is fine (assuming that concurrency/locking is not needed via a FOR UPDATE on the select that identifies the client identifiers to process).
A pipeline in this case does not do anything better. It introduces more moving parts - as a native PL/SQL can no longer be used to get the collection and step through it. A TABLE() SQL function is needed, a SQL statement, and more context switching.
The pipeline is simply an unnecessary layer between the code wanting to use the client identifiers and the SQL statement supplying the client identifiers. This approach of SQL -calls-> PIPELINE -calls-> MORE SQL is invariable wrong - unless the pipeline (PL/SQL code) does something very funky with the data from its SQL call, prior to piping it, that cannot be done using SQL.
If the "user" of that client identifiers is SQL code, then both the above methods are flawed. As this code is already SQL, why use PL/SQL to call more SQL code? Simply use the SQL code/logic that supplies the client identifier list directly in the SQL code that needs the client identifiers. This means something like SQL JOIN, EXISTS, or IN clauses.