Controlling the Type of Table Access

RLS has many uses beyond security and the simplification of application development models. RLS is also very helpful if you need to switch a table between read-only and read/write status, as determined by a variety of circumstances. Without RLS, DBAs could make an entire tablespace—but not the individual tables inside it—read-only or read/write. Even if a DBA wanted to take this approach, a tablespace could not be made read-only if it had any active transactions. As it may be impossible to find a period of time during which there are no transactions in a database, a tablespace may never actually be able to be made read-only. In such cases, RLS is the only viable solution.

Now, to be honest, RLS does not actually make a table read-only; it simply allows us to emulate that behavior by denying any attempts to change the contents of the table. The simplest way to do this is to apply a predicate to any UPDATE, DELETE, and INSERT that will always evaluate to FALSE—for example, 1=2.

Here is an example of making the EMP table read-only with this most basic of predicate functions:

    CREATE OR REPLACE FUNCTION make_read_only (
       p_schema_name   IN   VARCHAR2,
       p_object_name   IN   VARCHAR2
     )
       RETURN VARCHAR2
    IS
    BEGIN
       -- Only the owner of the predicate policy function can change
       -- the data in the table.
       IF (p_schema_name = USER)
       THEN
          RETURN NULL;
       ELSE
          RETURN '1=2';
       END IF;
    END;

Using this policy function, I can create an RLS policy on the table EMP for the DML statements ...

Get Oracle PL/SQL for DBAs now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.