Dynamic run-time objects in a query

Question

Hi everybody,
I came across some docs that say this Dynamic SQL fails:
CREATE PROCEDURE drop_table (table_name IN VARCHAR2) AS
BEGIN
EXECUTE IMMEDIATE ’DROP TABLE :tab’ USING table_name;
END;
Can someone explain why can't an object name be provided through a bind variable?
And the workaround, according to the docs is:
CREATE PROCEDURE drop_table (table_name IN VARCHAR2) AS
BEGIN
EXECUTE IMMEDIATE ’DROP TABLE ’ || table_name;
END;
Can you clarify on this?
Thanks.
-- Kishore.

Answer 1

Kishore:
It is not really the compilier that has the problem, it is just telling you that your code will not run when you try to execute it. When you use bind variables, as in Case 1, Oracle does not "see" the value of the bind variable until it actually executes the statement (we'll ignore peeking in 9.2). So, if you issue something like:
SELECT col
FROM t
WHERE id = :bvWhen Oracle parses the query, it will check to see that t exists, you can select from it, col exists in t, etc. Then, the optimizer will look at the WHERE clause and say "I've got an equality predicate, is there an index on id? If so, it will most likely choose an index based access plan. At this point, the optimizer has no idea what the value of bv is. Now, it will bind the value passed into the query and executes it.
This can lead to bad plans if you have skewed data and no histograms what if id has only 2 distinct values 1 row with id 1 and 99,999 with id 2. If you pass 1 for id, then id is the proper access plan. However, if you pass 2 then a full table scan is much more appropriate.
Now, think about the sequence of events when you try to bind the object name into DDL. What the database will see at run time from the execute immediate statement is:
DROP TABLE :bv;The same things happen in the parse phase as in the SELECT. Oracle will check whether the table exists, that you have the required permissions to drop it, etc. But, which table does it check? Remember, at this point Oracle does not know what value is in the bind variable.
In case 2, what the database will see as the sql statement when the procedure executes is:
DROP TABLE t;Now, at run time, Oracle can do all the required parse time checking and execute the sql statement. The compiler recognizes that the string passed to execute immediate will be at least parsable by the database and allows the compilation to succeed.
HTH
John