View + stored function + synonym for other user

Question

Dear All!
I've got a quite strange problem which I cannot decide whether it's caused by my lack of knowledge on the appropriate topic or by an Oracle bug. I'm already after some heavy googling on the topic and I was unable to track any valuable answers neither in forums nor in the Oracle documentation. I'll try to be as short and specific as possible.
Database: Oracle 10g
Result of "SELECT BANNER FROM V$VERSION":
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE     10.2.0.4.0     Production"
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I have two users in the database for a single Web application: UAPP01, which is the owner of application DB objects and UAPP02 which is the application user connecting to the DB. The application runs for quite many years by now and DB structure layout has always been following a simple logic: for each DB object used by the app. (tables, views, packages and stored procedures/functions) and found in the UAPP01 there exists a synonym in the UAPP02 schema. For the privileges to be set correctly a role is created: RL_MY_APPL which is granted the necessary privileges on objects of UAPP01 (CRUD on tables, SELECT on views, EXECUTE on procedures, etc..). This role is granted to UAPP02.
In the previous days I was about to extend the DB with a view that invokes a stored function. This pattern has already occured in the DB previously so I kept following existing conventions: I've created the stored function and the view in the UAPP01 schema, granted SELECT on the view to RL_MY_APPL and created the synonym for it in the UAPP02 schema. This is where the entire functionality began to act strange. I'll try to explain with a simplified example that was sufficient to reproduce the problem:
REM ========================================
REM Execute below code as UAPP01 user.
REM ========================================
REM Test function.
CREATE OR REPLACE FUNCTION testfunction(p_param NUMBER) RETURN NUMBER IS
BEGIN
RETURN p_param *2;
END;
REM Testview version 1. causing trouble.
CREATE OR REPLACE VIEW testview AS
WITH testdata AS
SELECT /*+ materialize*/ LEVEL AS d
FROM dual CONNECT BY LEVEL <= 100
SELECT a, b, c, SUM(d) AS sum_d
FROM
SELECT FLOOR(dbms_random.VALUE(1, 100)) a, FLOOR(dbms_random.VALUE(1, 100)) b, FLOOR(dbms_random.VALUE(1, 100)) c, testfunction(d) AS d
FROM testdata
GROUP BY CUBE(a, b, c)
REM Testview version 2. not causing trouble.
CREATE OR REPLACE VIEW testview AS
SELECT a, b, c, SUM(d) AS sum_d
FROM
SELECT FLOOR(dbms_random.VALUE(1, 100)) a, FLOOR(dbms_random.VALUE(1, 100)) b, FLOOR(dbms_random.VALUE(1, 100)) c, testfunction(d) AS d
FROM
SELECT LEVEL AS d FROM dual CONNECT BY LEVEL <= 100
GROUP BY (a, b, c)
REM Synonym.
CREATE OR REPLACE SYNONYM UAPP02.testview FOR UAPP01.testview;
REM Grants.
GRANT SELECT ON testview TO RL_MY_APPL;
When creating TESTVIEW with the 1 ^st^ version I cannot query it using the UAPP02 user, I'm constantly getting the error: ORA-00904: : invalid identifier. However, when I use the 2 ^nd^ version everything runs perfectly. What is common in the two cases is that both versions use the TESTFUNCTION function. I have not granted the EXECUTE rights on TESTFUNCTION to the RL_MY_APPL since it was never needed previously (for other views using stored functions) and as far as I know it's not necessary (as both the view and the function are owned by UAPP01). The strange thing in the above behaviour is that the function is used by both versions, however only one of them fails. This is where I thought it's not a granting issue, otherwise neither of the versions would have worked and I think I would have received a different error stating that UAPP02 lacks the necessary privileges on underlying objects of the view.
As I further digged into the problem by examining the EXPLAIN PLAN output for the two versions I found that version 1. leads to a TEMP TABLE TRANSFORMATION and to MULTI TABLE INSERTs, whereas version 2. simply executes the query without doing such things. In my setup I presume the MULTI TABLE INSERTs were caused by the GROUP BY CUBE. When I simply removed the CUBE and used only GROUP BY the TEMP TABLE TRANSFORMATION remained in place but the MULTI TABLE INSERTs disappeared. As a result of this small modification the view again began to work when I executed it through the synonym and using the UAPP02 user.
With the original DB objects of our application the behaviour is even more strange: the error comes up if I select from the view and filter for a column that is grouped in the query whereas it works correctly if I filter for the aggregated columns. However, I couldn't reproduce this with the above simplified example.
No problem occurs with any of the versions if I query the view using the UAPP01 user.
This hectic behaviour made me suspect that the TEMP TABLE TRANSFORMATION + MULTI TABLE INSERT + synonym + stored function combo appears to bring a strange Oracle bug to the surface...
As a final note: when executing GRANT EXECUTE ON TESTFUNCTION TO RL_MY_APPL everything works fine in all cases. I know I could simply live with this but I'd really like to get to the bottom of this. Although this extra GRANT appears to solve the problem I don't really trust it. I'd really like to avoid the bug emerging again in Production in case this extra GRANT were not sufficient due to some unknown misteries.
Excuse me, the post has become a bit lengthy. Thanks in advance for anyone who's willing to read through and answer it!
Regards,
Krisztian Balazs Szaniszlo

Answer 1

The error is thrown at run-time and only for the UAPP02 (second) user.
The problem is that the appearance of errors is independent of whether the query contains the call to the stored function or not.
So far I thought that if I use a stored function indirectly, like in this setup: UAPP02.synonym -> UAPP01.view -> UAPP01.stored function, then I don't need the grant. Of course, I understand that if I had used it directly, like :UAPP02.synonym -> UAPP01.stored function then I'd need the GRANT EXECUTE.
Shall I just ignore the strange behaviour and go on by adding GRANT EXECUTE privilege on all the functions used indirectly through views? It seems to solve the problem, but this behaviour is disturbing me quite and I fear the real root cause of the problem can emerge later in a different fashion.