Passing where cluase as parameter for cursor

Question

I want to pass where clause of cursor as parameter.... how can I do that?
say I want cursor as,
cursor c1 is select fname, mname from person where :param;
where :param is a value I want to pass in declare section

Answer 1

I want to pass where clause of cursor as parameter.... how can I do that?Yes.
cursor c1 is select fname, mname from person where :param;
where :param is a value I want to pass in declare sectionYou can also shoot yourself in the foot using a 357 Magnum.
Neither is recommended - unless you are a professional idiot. Which I doubt as these are typically your Darwin Award Winners.
Why is it bad to to have "+WHERE :param+"?
Bind variables. If the WHERE clause is passed as a dynamic string. this will usually be implemented in the following fashion:
SQL> create or replace procedure smellyFoo( filterClause varchar2, refCur in out sys_refcursor ) is
  2  begin
  3          open refCur for
  4          'select owner, object_id, object_name from all_objects where owner != ''SYS'' and '||filterClause||' order by 1,2';
  5  end;
  6  /
Procedure created.
SQL>
SQL> var c refcursor
SQL> exec smellyFoo( 'object_type=''TABLE'' and rownum <11', :c );
PL/SQL procedure successfully completed.
SQL>
SQL> print c
OWNER       OBJECT_ID OBJECT_NAME
OUTLN             452 OL$
OUTLN             453 OL$HINTS
OUTLN             456 OL$NODES
SYSTEM           3621 MVIEW$_ADV_WORKLOAD
SYSTEM           3624 MVIEW$_ADV_BASETABLE
SYSTEM           3626 MVIEW$_ADV_SQLDEPEND
SYSTEM           3628 MVIEW$_ADV_PRETTY
SYSTEM           3630 MVIEW$_ADV_TEMP
SYSTEM           3632 MVIEW$_ADV_FILTER
SYSTEM           3634 MVIEW$_ADV_LOG
10 rows selected.
SQL>What's wrong with this? The filter clause contains literals. Not bind variables. Which means that non-sharable SQL will be created. This means more cursors (for same SQLs with different literal values) in the shared pool. Different sizes SQLs that leads to fragmentation of the shared pool memory. More hard parsing. Bigger delay in parsing as there are more cursors to scan in the shared pool (useless exercise) as there are no existing cursors that are sharable and can be re-used.
So what would the correct way be? The client passing a filter clause as a proper bind variable string, and also passing (separately) the values for those bind variables. But this is not easy to code, especially when dealing with filter clauses that may contain no bind variables. or a 100 bind variables.
Also, the call interface the client needs to use will become a lot more complex as the client now not only needs to build a proper string containing bind variables, it also need to make sure it pass the values for those variables in the correct order.
So why? Why do any of this? What is the requirement that lead you to this "solution" where the client can dynamically decide on what the filter criteria is?
Surely, there must be a reason to this madness of the client wanting to throw any filter clause at a SQL cursor... and surely, that is what needs to be identified and analysed and resolved - instead of wanting to create hacks like the above. Causing performance issues. Not to mention opening a security hole that is ideal for SQL injection.