Using a comma-separated list in an SQL query

SQL has arrays

A frequently-asked Oracle question:

My procedure is passed a comma-separated list of IDs, for example 7369,7499,7839,7902. I tried to use it in my code like this:

DECLARE
	p_empno_list CONSTANT VARCHAR2(20) := '7369,7499,7839,7902';
BEGIN
	FOR r IN (
		SELECT * FROM emp
		WHERE  empno IN (p_empno_list)
		)
	LOOP
		DBMS_OUTPUT.PUT_LINE(RPAD(r.empno,9) || r.ename);
	END LOOP;
END;
/

but it just gives me an error:1

ERROR at line 1:
ORA-01722: invalid number
ORA-06512: at line 4

Clearly, SQL does not consider

WHERE  empno IN (p_empno_list)

to be equivalent to

WHERE  empno IN (7369,7499,7839,7902)

And of course is cannot, and should not. What if you had a value such as '123, Fake St, Springfield' that represented a single address line? How would you feel if you used v_address_line in a query similar to the one above, and SQL chose to treat it as not one but three values ('123', 'Fake St' and 'Springfield'), just because it happened to contain commas and the query used IN? It would be wrong! SQL has to treat each variable as one value.

What the programmer is really looking for is a different type of variable that explicitly represents a set of values. Fortunately Oracle SQL supports exactly this, in the form of collections.2

You create a scalar collection type3 like this:

CREATE TYPE INTEGER_TT AS TABLE OF INTEGER
/

The name itself is not important except that it should give an indication of what it represents, and the fact that you will have to live with it. I use _TT ("table type") for collection types (see my PL/SQL Coding Standards for more suggestions regarding naming standards). Since it should be a generic type that you will reuse in many different places, it is better to refer to the base datatype, INTEGER, than the fact that right now you want it for an employee ID. While you are at it, why not create a couple more:

CREATE TYPE NUMBER_TT AS TABLE OF NUMBER
/

CREATE TYPE VARCHAR2_TT AS TABLE OF VARCHAR2(4000)
/

Now, when your list of IDs is an INTEGER_TT instead of a plain old character string, you can use it in SQL:

DECLARE
	p_empno_list CONSTANT INTEGER_TT := INTEGER_TT(7369,7499,7839,7902);
BEGIN
	FOR r IN (
		SELECT empno, ename4
		FROM   emp
		WHERE  empno IN
		       ( SELECT column_value5
		         FROM   TABLE(p_empno_list) )
		)
	LOOP
		DBMS_OUTPUT.PUT_LINE(RPAD(r.empno,9) || r.ename);
	END LOOP;
END;
/

7369     SMITH
7499     ALLEN
7839     KING
7902     FORD

The only problem now is how to get an INTEGER_TT collection into your procedure in place of a character string. The simplest solution is to change your procedure's parameter list so that it is by definition passed one. If an existing application has been built to pass character strings (I can never understand why anyone would do this as it just creates more work, but apparently it happens frequently), here are some suggestions:

More suggestions

© William Robertson 2004, 2007 www.williamrobertson.net

Bookmark and Share

1: When SQL is expecting a character string such as SMITH, but is passed a comma-separated list such as SMITH,JONES,FORD,MILLER, no error is produced, but the query simply returns no rows.
2: The only types of collection that SQL can handle are those you define in SQL - types defined in a PL/SQL package are not recognised (PL/SQL understands SQL, not the other way around). This gives you a choice between Nested Table types and VARRAYs. I recommend using Nested Table types and not VARRAYs unless there is some good reason to set a limit to the number of elements (which VARRAYs let you do), for example if the collection is designed to contain some particular number of elements (twelve months, seven days, five sexes etc).
3: You can check the scalar collection types already available with this query (if the popup footnote won't stay put long enough to copy and paste, view the source of this document):

SELECT ct.owner, ct.type_name, ct.elem_type_name, ct.length
FROM   all_coll_types ct
     , all_types ot
WHERE  ct.coll_type = 'TABLE'
AND    ot.type_name(+) = ct.elem_type_name
AND    ot.owner(+) = ct.elem_type_owner
AND    ot.type_name IS NULL
ORDER BY ct.owner, ct.type_name;
4: In 9i, SELECT * used with TABLE() and no explicit CAST() gives error ORA-22905 cannot access rows from a non-nested table item.
5: COLUMN_VALUE is the default attribute name in a scalar collection type.
6: From Frank Kulash, in a post on OTN.