Code returning NULL

Question

T1 (Table and columns & data ) used in my example
create table T1 (col1 number,col2 number);
col1 col2
1 5
2 5
3 5
4 5
11 6
12 6
13 6
14 6
CREATE OR REPLACE FUNCTION TEST (par NUMBER) RETURN VARCHAR2 IS
l_concat VARCHAR2(32767) ;
BEGIN
select wm_concat(col1) into l_concat from t1 where col2=par;
RETURN l_concat;
END;
select TEST(5) from dual;
The above example always returns a NULL as opposed to (1,2,3,4);
CREATE OR REPLACE FUNCTION TEST (par NUMBER) RETURN VARCHAR2 IS
l_concat VARCHAR2(32767) ;
l_str varchar2(32767);
BEGIN
l_str:='select wm_concat(col1) from t1 where col2=:b';
execute immediate l_str into l_concat using par;
RETURN l_concat;
END;
select TEST(5) from dual;
This returns the correct answer .i.e. (1,2,3,4);
My question is why my first code returning NULL? Is there any restriction using aggregate functions inside
plsql code ?

Answer 1

BluShadow wrote:
The in paramter has the same name as one of the column . Thus the select query was not taking the filtering predicate as the in parameter col1 ,rather it was
using the column's value for filtering each row and hence the wm_concat was not getting any row to concatenate .That's why you should use a good coding standard and perhaps prefix parameters with "p" or "p_" and local variables with "v" or "v_" etc.Smacks too much of archaic Hungarian notation. :-)
Explicit scope definition is supported by PL/SQL. So why invent a new manual standard for scope, when there exists one already?
SQL> create or replace procedure FooProc( empNo emp.empno%Type ) is
  2          empRow  emp%RowType;
  3  begin
  4          select
  5                  e.* into empRow
  6          from    emp e
  7          where   e.empno = FooProc.empNo;
  8 
  9          dbms_output.put_line(
10                  'Employee '||empNo||' is '||empRow.ename||
11                  ', and employed as '||empRow.job
12          );
13  end;
14  /
Procedure created.
SQL>
SQL>
SQL> exec FooProc(7369)
Employee 7369 is SMITH, and employed as CLERK
PL/SQL procedure successfully completed.
SQL> Personally, I find the v_ and p_ prefix approach quite silly - attempting to address an issue that is already solved by explicit PL/SQL scope.
Never mind that the approach of using different prefixes, attempts to identify scope - and goes down the exact same slippery scope that Hungarian notation did. Which resulted in the death of this misguided standard, many years ago.
Frustrates me to no end to see the exact SAME mistakes made in PL/SQL that were made a decade or more ago - where lessons learned since then are conveniently ignored when it comes to PL/SQL programming.
It is still seems to be the Dark Ages when it comes to PL/SQL development.... :-(