Using Hashing Triggers and View

Hashing Triggers use protection functions in triggers in the same manner as encryption.

Oracle example:

CREATE OR REPLACE TRIGGER SCOTT.NAMETABLE_INS
INSTEAD OF INSERT ON SCOTT.NAMETABLE
FOR EACH ROW
DECLARE
NAME_ RAW(2000) := NULL;

BEGIN
           **NAME\_:=PTY.INS\_HASH\_VARCHAR2\('HashDE', :new.NAME, 0\)**;

           INSERT INTO SCOTT.NAMETABLE_ENC(IDENT, NAME)
           VALUES(:new.IDENT, NAME_);
END;


CREATE OR REPLACE TRIGGER SCOTT.NAMETABLE_UPD
INSTEAD OF UPDATE ON SCOTT.NAMETABLE
FOR EACH ROW
DECLARE
NAME_ RAW(2000) := NULL;

BEGIN
           **PTY.SEL\_CHECK\('HashDE'\);

           NAME\_:=PTY.UPD\_HASH\_VARCHAR2\('HashDE', :new.NAME, 0\)**;

           IF: old.IDENT = :new.IDENT THEN
                      UPDATE NAMETABLE_ENC SET 
                      NAME= NAME_,
                      WHERE IDENT=:old.IDENT;
           ELSE
                      UPDATE NAMETABLE_ENC SET 
                      IDENT=:new.IDENT, 
                      NAME= NAME_,
                      WHERE IDENT=:old.IDENT;
           END IF;
END;

The view selects the hash value directly from the table instead of running a decrypt function. To make this work as a normal trigger/view solution, the binary data type is cast into the original data type. In Oracle it should be VARCHAR2. The data type must be cast to insert data through the view as usual.

CREATE OR REPLACE VIEW SCOTT.NAMETABLE(IDENT, 
NAME)
AS SELECT IDENT, utl\_raw.cast\_to\_varchar2\(NAME\))
FROM SCOTT.NAMETABLE_ENC;

The application handles the return value, which will now be a 20 byte or 32 byte binary string converted into a character string.


Last modified : August 20, 2025