Comments on: Poor man's VPD – Virtual Private Database before 8i and in Standard Edition Databases

By: Lucas Jellema

Lucas Jellema — Sat, 08 Oct 2005 16:56:47 +0000

I have not said as much, but it is probably obvious that when you want to impose policies on Insert, Update and Delete operations – which VPD can also do for you as of release 10g – you have to rely on either Insert, Update and Delete triggers – typically row level – or a View with a Check Option in those circumstances where your DML policies coincide with your Select policy. A View WITH CHECK option ensures that any INSERT of UPDATE will never lead to a result that can not be seen in the view itself.

By: Anton

Anton — Thu, 06 Oct 2005 11:34:03 +0000

For the Dynamic predicate could also something like

CREATE OR REPLACE PACKAGE tx IS
  TYPE t_emp IS TABLE OF emp%ROWTYPE;
END;
/
CREATE OR REPLACE FUNCTION y( p_limit in pls_integer := 1000 )
RETURN tx.t_emp pipelined
IS
  t_cur sys_refcursor;
  a_cur tx.t_emp;
  l_predicate varchar2(2000):= 'job = ''CLERK''';
BEGIN
  OPEN t_cur FOR 'select * from scott.emp where ' || l_predicate;
  LOOP
    FETCH t_cur BULK COLLECT INTO a_cur LIMIT p_limit;
    EXIT WHEN a_cur.count = 0;
    FOR i IN a_cur.first .. a_cur.last
    LOOP
      PIPE ROW( a_cur( i ) );
    END LOOP;
    EXIT WHEN t_cur%NOTFOUND;
  END LOOP
  RETURN;
END;
/
CREATE OR REPLACE VIEW emp AS SELECT * FROM TABLE( y )
/

be used. Bulk collecting a refcursor wasn’t available in Oracle 8i offcourse.

By: Eric van Mourik

Eric van Mourik — Tue, 04 Oct 2005 14:48:12 +0000

Interesting post! Especially the ways you describe to use dynamic predicates.

The application developed and marketed by my former employer (ORCA by Truston) is/was based on such an implemention of a “Poor Man’s VPN”.

You are stating two options for the creation of the views:
1. Rename all tables and create views in the same schema using the old tablenames.
2. Create the views in a second schema.

In my opinion, there is a third (more convienant) option: Create the views with a different name in the primary schema.
For example: The view based on table EMP will be named EMP_.
(Another – less transparant – way is explicitly creating the table with names in uppercase, and the views with names in lowercase (create view “emp” as select * from emp).)
Next, the (public) synonym that is (re)created for view EMP_ (or “emp”) will get the “original” name EMP.

Not stated in your post – but of course essential to the concept – is to revoke all the rights on the underlaying tables!
Otherwise users can easily ignore the authorization policies by prefixing their SQL-statements with the schema name.
This final step is often forgotten, as many developers do not realize that there are other ways to access the data then by means of the application/UI they are developing.