APEX$F1 is the name of the first bind variable generated by APEX, whenever APEX generates SQL for any component. When the page is loaded, and APEX fetches the display value, the first bind variable is the return value to look up the display value for, as APEX executes the LOV query with a generated WHERE clause of {return-column} = :APEX$F1.

Documenting APEX$F1 would lead to APEX applications tightly tied to internal APEX query execution. That would lead to potential future query execution optimizations not possible any more, as APEX tied itself to these documented bind variables. Or … we do these things and break applications. Both is IMO not feasible.

I believe that this idea is talking about different things:

1. Oracle TEXT Score:
   The actual requirement is to get access to the SCORE. So the enhancement to APEX would be to automatically provide the SCORE as soon as a TEXT query is added to a query - not only for LOVs but also for reports or faceted search. That SCORE column should then be provided under a certain, known name. So APEX should make sure that this SCORE column is always returned to the component; containing NULL when no TEXT query is given, and the value if a TEXT query is given.
   Access to bind variables should not be required for this; this should IMO be done at a higher level.
    
2. Access to LOV values, bind variables:
   Instead of tapping into the internals of APEX query execution, a shared LOV with an interface might be the better option. So when defining an LOV, it also gets a definition of input parameters. When the LOV is used, concrete page items can be mapped to these parameters. In the LOV query, the parameters are used instead of page items or internal bind variables.

So, I think, these are actually two ideas, and both with a different scope than described here - what do you think?

regards

-Carsten

Carsten, I vote for #2 it’s the ideal solution.

Carsten,

I agree with your analysis--and I want both :)

For the second case, what I really want is access to the value of the item. For example, I might have a shared select list that should only show doctors that accepting new patients--unless I already have that doctor. So the the query would be:

select doctor_name display_value, id return_value

from doctors

where accepting_new_patients = ‘Y’

or id = :P12_DOCTOR_ID

But, of course, that doesn't work well as a shared LOV. So, maybe something like this:

select doctor_name display_value, id return_value

from doctors

where accepting_new_patients = ‘Y’

or id = :APEX$THIS

Where :APEX$THIS represents the value of the item associated with the LOV.

Sounds like this one too 

https://apex.oracle.com/ideas/FR-1988