Oracle substitutes asterisk to all columns in a view - oracle

Question

I've just bumped into the case when I have a view that has an asterisk reference to one of underlying tables. After compilation this asterisk sign is being exchanged to all column list and I don't want it to happen. See example below:
create or replace view test_view_cols as
select 1 f_1,
2 f_2,
3 f_3
from dual
/
create or replace view test_interface as
select d.*
from test_view_cols d
/
create or replace view test_view_cols as
select 1 f_1,
2 f_2,
3 f_3,
4 f_4,
5 f_5
from dual
/
select count(*) col_cnt -- returns 3 and not 5
from user_tab_cols s
where s.TABLE_NAME = 'TEST_INTERFACE';
select s.text
from user_views s
where s.VIEW_NAME = 'TEST_INTERFACE'
/* returns
select d."F_1",d."F_2",d."F_3"
from test_view_cols d
*/
But I don't want asterisk to be exchanged and I want have all the columns from test_view_cols in test_interface view.
Can I somehow force Oracle to keep an asterisk in an underlying query?
Oracle 11gR2

Answer 1

No.
You can't define a view that returns a variable number of columns depending on the changing definition of an underlying object (whether that underlying object is a table or a view). You could define a stored procedure that has an OUT parameter of type SYS_REFCURSOR that would return whatever columns are in the underlying object. You should also be able to define a pipelined table function that returns a different number of columns based on the underlying object-- that does get much easier in more recent versions, though.

Answer 2

You need after each change of the underlining object simple re-create the interface view as well.
create or replace view test_interface as
select d.*
from test_view_cols d
Than is the view definition again adjusted to the new object. The start * is expanded in the view compilation not in the query.
What you can use starting with Oracle 19c (or better 21c) is SQL Macro
The TABLE SQL Macros are defined similar as function, but they return text of the subquery that will be used.
You can define the SQL Macro that returns all columns of the base view as follows
create or replace function test_interface
return varchar2 SQL_MACRO
is
begin
return q'[
select * from test_view_cols]';
end;
/
You use the SQL Macro in the FROM clause
select * from test_interface();
This query return on the first run the three columns of the underlining view.
After the view is modified, you get back the five columns. Why?
The SQL Macro is activated only at parse time, so you should take some care, that you do not get the old columns state from the cached cursor.
But this is not a problem, because by changing the underlining view your cursor is automatically invalidated and must be reparsed with the new definition.
But SQL Macros are even more powerful. You can define one universal interface SQL Macro that can be applied on all your tested objects by passing the name of the underlining view or table as a parameter:
create function my_interface (t DBMS_TF.Table_t)
return varchar2 SQL_MACRO(TABLE)
is
begin
return q'[
select * from t]';
end;
/
In the query you than pass the name of the tested view
select * from my_interface(test_view_cols);
More information and examples of SQL Macros can be found here and there.