11g PIVOT uses static columns - why why why???

Question

I am very curios to know why we have to hard-code the "pivot in" clause in a pivot query. Does this not defeat the purpose of pivoting?
we have to write this:
SELECT *
FROM (SELECT customer_id, product_code, quantity
FROM pivot_test)
PIVOT (SUM(quantity) AS sum_quantity FOR (product_code) IN ('A' AS a, 'B' AS b, 'C' AS c))
ORDER BY customer_id;
Why can we not put a subquery in the "IN" clause? Or even better, leave it blank to indicate we are pivoting for all.
I know you can do something like this with the PIVOT XML function, but I want columns in the result, not XML. And I also do not want to build the query as a string and execute it like that, it gets really messy and I feel sorry for the next bloke who needs to take over from me.
Does anybody know why this seems to not be possible for ORACLE?
Thanks all.

Answer 1

In addition to the excellent relational theory reasons the SQL standard (and relational database vendors) can't do dynamic pivots, there are important practical problems.
Every API that interacts with any database (ODBC, JDBC, ODP.Net, ADO, DAO, OLE DB, OO4O, etc.) goes through a series of steps in order to execute a SQL statement.
1) The statement is prepared.
2) The bind variables are bound and return variables are created
3) The statement is executed.
Preparing the statement involves the database parsing the query (but not executing it). This provides the client with a statement handle that can be interrogated to, for example, describe the result set to expect. This allows the client to determine that, for example, a query is going to return 5 columns, the first of which is an integer and the next 4 of which are VARCHAR2(100)'s. The client then knows what data structures it needs to allocate. Since this statement handle is potentially going to be cached and reused many times with many different sets of bind variables, the structure of the result needs to be fixed.
If a database permitted the structure of the query to change because data changed, it would cause massive havoc across every application that interacted with the database. You'd have to add something to every database API that allowed the database to come back from an attempt to execute a query and say "hey, I know I told you a while ago that this query was going to return 5 columns-- turns out, now it returns 6 (or 4 or 17)". Tons of code that relies on these APIs would need to be rewritten to be able to handle that exception, discard the cached handles, reallocate the data structures, re-execute the query, and figure out what, if any, downstream impacts that has on the application code. That would be a massive undertaking and would create much more work than would be saved by allowing a dynamic pivot.
Justin