How to adapt function for direct using for IN/NOT IN clause

Question

Hello
I have following function:
create or replace
function all_userids return UserTypeIDTAB authid definer
is
l_emp_tab UserTypeIDTAB := UserTypeIDTAB();
begin
for r in (select userid from usertab where userid <=10)
loop      
l_emp_tab.extend;
l_emp_tab(l_emp_tab.count) := r.userid;
end loop;
return l_emp_tab;
end;
where type UserTypeIDTAB was created by following:
create or replace type UserTypeIDTAB as table of number;
This function can be called in SQL:
select * from usertab where userid in (select * from table(all_userids))
But what I want to achieve is that it will be possible with shorter query like:
select * from usertab where userid in all_userids
or
select * from usertab where userid not in all_userids
In this case I have got following error:
00932. 00000 - "inconsistent datatypes: expected %s got %s"
Is it possible? What must be done for it? What does expect IN/NOT IN clause?
thanks

Answer 1

Metalpalo wrote:
What duplicate? And what would you achieve by "eliminating" this duplicate?The term duplicate by me is following subselect code:
(SELECT LISTITEMID FROM LISTTAB WHERE LISTID = ?)
This condition is to big when I set e.g. 100 filters. Therefore I want to replace it with something shorter.There is nothing shorter. In SQL language, you cannot define procedures or functions.
Putting that SQL statement as a view? That will be of no real benefit in making the statement shorter. There are two approaches. The first one is not very sensible as it does not provide any benefit:
create or replace view item_list as select item_id from list_tabTo "+pass parameters+" to the view (as you would to a function or a procedure), you need to use predicates. The CBO is clever enough to push these into the actual SQL that defines the view where possible. So using it:
select item_id from item_list where list_id = 1As you can see - nothing gained as the view SQL looks exactly like the underlying source SQL and the view provides no benefits.
The second method is to define views per list ID. For example:
create or replace view item_list_1 as select item_id from list_tab where list_id = 1
create or replace view item_list_2 as select item_id from list_tab where list_id = 2To use that:
where  parent_id in (select item_id from item_list_1) and child_id in (select item_id from item_list_2) The predicate now needs not be specified. But you need a view for each unique predicate that would have been used. Perhaps do-able when dealing with a small number of lists - but generally, this approach will not be useful and will require additional maintenance (creating views for new lists, dropping views for lists no longer valid, etc).
Thus using orignal SQL statement as it is, is IMO correct and should be used like that. And if you have a billion SQL statements that needs to apply that sub-select filter, then yes - you will need to code that SQL as a sub-select a billion times.
Nothing wrong with that. It is not duplication. And the fact that you cannot create "short cut" code in this case, is simply an issue of how the language is designed.
In Cobol we need to do this to increment a counter:
ADD 1 TO COUNTER.
In PL/SQL:
cnt := cnt + 1;
In C/C++:
i++;
In Delphi Pascal (generating optimal machine code):
Inc( cnt );
Etc.
It is wrong thinking that because another language allows you to do this by writing a fewer characters less, you now also need to pursue fewer less characters in the current language.
You need to adhere to the syntax, rules and fundamentals of the language you're using. And in SQL, it is perfectly fine to code that SQL statement, with a different predicate, multiple times. This is simply how the SQL language works.