Encapsulating a query in a view with "parameters"

Question

I have a complex query using analytic functions and an inline view, something like:
select * from (
select a, b, c, row_number() over (partition by x, order by y) rn
where b like 'XXX%'
where rn = 1;
(The actual query is a little more complex, but that's the idea). This query performs very well.
As the query is of some general use, I'd like to package it up. However, the 'XXX%' pattern will vary with each use.
If I try to make a view v which is the query minus the XXX% where clause, the optimiser cannot merge the where clause and the view in a query like
select * from v where b like 'XXX%'
This doesn't surprise me too much - merging like that is going to be hard (if indeed it's possible at all!) As a result, the query using the view is significantly slower.
Is there any way of making my original query reusable? For PL/SQL, I can use a function returning a REF CURSOR and taking the pattern as a parameter - but I need to use this from SQL.
I could write a pipelined function and then do select * from table(my_fn('XXX%')). However, this is in 8i, where I don't have that option. Also, for a pipelined function, I'd need to define a record type and an associated table type - what seems like quite a lot of code for what is conceptually pretty simple.
Have I missed any obvious options? I can live with the pipelined function and "no way until 9i" - but only as a general answer. For my current specific issue, that's equivalent to "you can't do this".
I thought of using SYS_CONTEXT, but if I understand correctly, I can only use that in PL/SQL, as I can't set the context outside of an authorised package. Is that right, or is there a way I could use contexts? (Hmm, I need to be able to use the query from SQ, but I could probably execute a PL/SQL procedure before running the query, to set things up - does that help?)
Thanks for any suggestions.
Paul.

Answer 1

SYS_CONTEXT would work, as would package global variables.
I once wrote an example about this (though with TABLE function but for your case the principle stays the same) which you may find here:
Re: TABLE FUNCTION - Using database view - send parameters to the function.
hth, michael