Equivalent for AUTHID CURRENT_USER in view

Question

Hi, I'm facing a problem with a view which belongs to user a and I would like to select tables from user b.
Exemple :
user a - table MYTAB
user b - table MYTAB
done by user a : "create or replace view MYVIEW as select * from MYTAB"
grants and synonyms done for both users
if I execute from user b : "select * from MYVIEW", I get the data from a.MYTAB, not b.MYTAB
What can I do to force MYVIEW to select from current user's table ? (juste like the AUTHID CURRENT_USER for procs)
Do I have to create the view in all schemas ?
Thx in advance

Answer 1

I wanted exactly the same thing. It's not ideal, but here is what I did. I did it like this so that I can hide away any complexity from other users, and just give them a view that they need not worry about the internal nuts and bolts of.
It's a bit fiddly, but it goes like this.
1. In schema A, create an AUTHID CURRENT_USER package. Let's call it pkg_A.
2. Add a PIPELINED table function to pkg_A, let's call it pipe_rows. For this thread/example, into this function you put the query in question.
3. Or, you might put the query in a global, public pkg cursor. That way, you can declare a TABLE of that %ROWTYPE. A pipelined function can then return this table-type.
4. In schema B, create a view, let's call it pkg_A_pipe_rows_vw_in_B. Yes, this means creating a view in Schema-B, which we were hoping to avoid, but this is really simple, and now all the 'nuts and bolts' are common, generic, and hidden away in Schema-A. This view is as simple as:-
CREATE OR REPLACE VIEW pkg_A_pipe_rows_vw_in_B AS
SELECT * FROM TABLE(pkg_A.pipe_rows);Note, this view MUST be in Schema-B, as previously pointed out, a view <b>always</b> resolves to objects in the schema into which the view is compiled. This is very confusing, given that the package being called is AUTHID CURRENT_USER.
This code demo's points 1-3.
CREATE OR REPLACE PACKAGE pkg_A
AUTHID CURRENT_USER AS
    CURSOR G_PIPE_CSR IS SELECT * FROM DUAL; -- not good eg, need tab in BOTH schemas with diff data
    TYPE G_PIPE_TABLE IS TABLE OF G_PIPE_CSR %ROWTYPE;
    FUNCTION pipe_rows
    ( param1 IN VARCHAR2 := 'DEFAULT' ) -- can pass params but not from the view in (4) so must default
    RETURN G_PIPE_TABLE
    PIPELINED;
END;
CREATE OR REPLACE PACKAGE BODY pkg_A AS
    FUNCTION pipe_rows
    ( param1 IN VARCHAR2 := 'DEFAULT' ) -- can pass params but not from the view in (4) so must default
    RETURN G_PIPE_TABLE
    PIPELINED IS
        l_pipe_row G_PIPE_CSR %ROWTYPE;
    BEGIN
        OPEN G_PIPE_CSR;
        LOOP
            FETCH G_PIPE_CSR INTO l_pipe_row;
            EXIT WHEN G_PIPE_CSR %NOTFOUND;
            PIPE ROW(l_pipe_row);
        END LOOP;
        RETURN;
    END;
END;
/As you can't pass params from the view in schema-B, what you can do is provide further 'set' procedures in the package which assign values to global vars, then use the global vars (or public 'get' functions that return the same), when you issue the query. This, again, isn't brilliant. You could set local vars based on the user-id, time of day, etc, etc, and use these in the query.
Btw, I disagree with William's point:->
For this reason invoker's rights procedures are usually best for utilities that don't do DML.>
Providing these utilities are well advertised as resolving against the CURRENT_USER's schema, this is how you can provide generic access mechanisms for like-data in disparate schemas. For example, we are client driven, client A's data is separate from client B's data, but we provide the same service to both parties. (Although, William did say "usually"!)
Regards,
Cloink.