Just as with tables, user-facing views should be secured. You can do this either explicitly, by adding privilege testing functions to the view definitions, or implicitly by building the views on tables that have already been secured. In this latter case, the views will need to be owned by a separate database role from that which owns the tables as views are processed with the access rights of their owners.

This is best explained by example. Here is an example from the demo:

create or replace
view party_roles (
    party_id,
    role_name,
    context_type,
    corp_context_id,
    org_context_id) as
select ar.accessor_id, r.role_name,
       st.scope_type_name,
       case when ar.context_type_id = 3
       then ar.context_id
       else null
       end,
       case when ar.context_type_id = 4
       then ar.context_id
       else null
       end 
  from veil2.accessor_roles ar
 inner join veil2.roles r
         on r.role_id = ar.role_id
 inner join veil2.scope_types st
         on st.scope_type_id = ar.context_type_id
 where veil2.i_have_global_priv(20)
    or veil2.i_have_priv_in_scope(20, 3, context_id)
    or veil2.i_have_priv_in_scope(20, 4, context_id);
    

Note that if the view is updatable you will also need to build instead-of triggers or some equivalent, that take into account update, insert and delete privileges. One wrinkle with updatable views is that they should not allow modifications of rows that they would not be allowed to see, so the select privilege must usually be explicitly tested in addition to the select, insert or update privilege.

Views do provide some interesting possibilities though. One is to use the privilege testing functions on specific columns to make access controls even more fine-grained.