I've always been disappointed that this feature was missing from the IR

Absolutely. I've created variable IR column headings using hidden page items, but it is a pain to do that.

Great feature in classic reports which should be universally available in other report types.

Let's say I want to use one report to display the fields and results of a variety of queries. I can do this with a Classic Report but I'd like to be able to do with an IR/IG because these reports have obvious advantages over the Classic Report.

What is the actual use case for this? As Oracle have repeatedly pointed out, those “obvious advantages” are predicated on IR and IG data sources returning an immutable set of columns: same number, same names/aliases, same data types.

There are situations where dynamically labelling the columns would be useful—e.g. matrix reports and reports on APEX collections—but a single report region returning heterogeneously shaped data is not feasible.

Here is a use-case…

There might be a hundred columns of data in a table. Each user may only have an interest in half a dozen columns out of the full set of 100 and a different half dozen for each user.

Imagine a page on which the user can choose which columns are of interest to them out of that 100. The requested data, for a range of rows, is to be displayed to the user in a table/grid AFTER the user has selected which columns they like.

The SQL query's SELECT clause cannot be a hard-coded list of columns since it is determined by the user at runtime.

However, a PL/SQL method could be defined that accepts the list of columns of interest selected by the user as a parameter. The method could dynamically build SQL for the columns specified and then return only that data wrapped up in a single JSON/XML CLOB.

The CLOB could contain not only the rows of data, but their column labels. Apex then presents a table with the column labels defined in the CLOB as well as the rows of the data, also found in the CLOB.

Apex would need to define the structure of the JSON/XML it expects to receive to build the table. Developers would need to adhere to that structure when defining the CLOB returned by their PL/SQL method.

@jsheppard thanks for the detailed use-case

@fac586 and @jayson hanes

The video below shows the use case that allows a single report (classic or IR) to report on every table available in the schema. 

https://www.youtube.com/watch?v=fuA8_RbFk00

If you start at 2 minutes 15 seconds and watch it will show how to do this with both a classic report and an IR.

You can also install the APEX application from my Git repo

https://github.com/ainielse/rando

It is the f_one_report.sql file.

A single IR works for every table in  you schema.

@anton: that is just the problem with the IR: you created 60 hidden items.

@ino.laurensse

Exactly! That's why this is a good idea. So that I don't have to do that.