Parameterized Views for User Reports

Question

I would like to be able to define a view such as:
create view dept_emps(p_dept in varchar2) as
select * from emps where dept = p_dept);
and use this view to define a SQL Dev drilldown report with SQL such as:
select * from dept_emps(:DEPT)
where :DEPT is a bind variable passed from a selected depts report row.
Oracle apparently does not support parameterized view definitions as suggested above, but I have found an article by Tom Kyte on the issue of parameterizing views, where Tom suggests using DBMS_SESSION.SET_CONTEXT (called within a user package) to set context values that can be retrieved in a view using the SYS_CONTEXT function. I can get this approach to work at the SQL prompt to work around the lack of formal view parameters. I have a package which defines a procedure which sets context values that I can then retrieve within a view using the SYS_CONTEXT function.
To use this approach when defining a SQL Developer user report, the SQL for the report would need to be logically something like (which works fine at an SQL prompt):
exec ssuper_context.set_ctx('DEPT', :DEPT) - - Call user procedure to assign context variable 'DEPT' with bind value from parent report
select * from dept_emps
where view dept_emps uses function SYS_CONTEXT to return the value for context variable 'DEPT'.
SQL Developer complains about this as the SQL for a user-defined report. Can anyone suggest how I might pass a bind value from a selected parent record to a view which implements a drilldown report?
TIA Jon

Answer 1

I met CSI at a kongress a few weeks ago and pressed them a bit on how this works. Eventually they fezzed up about the table read but mentioned that in the next release being developed it would be different...
Problems with this is that the FM has a couple of limitations, so you cannot read all tables correctly... so you end up reading some of the wrong ones or taking the easy ones.
Another option is to let the database itself do the hard work, to get back to the performance aspect.
Anyway, for neither of these two do you need any tcode, so indeed we are drifting off topic...