Establishing whether an accessor has a given privilege in a given scope is a complex operation. Privileges are assigned via roles, which may be assigned by other roles. Furthermore the contexts in which those role assignments occur, and the context of the role to role mappings are largely user-defined. To deal with both the complexity, and the need to allow user-customization, we determine an accessor's privileges through views. For performance reasons, some of these views are materialized. Where materialized views alone are not enough we use cache tables which are similar in nature to materialized views but: are implemented manually; can be refreshed incrementally; can be indexed. The (clickable) diagram above shows the relationship of views with each other and with Veil2, and other, tables and functions. The bottom-most view in the diagram, session_privileges_v provides the data that determines an accessors privileges. This view is used directly by the function load_session_privs to load the set of applicable roles and privileges, in all applicable contexts for an accessor's session. The performance of this view is critical, and has been carefully developed and optimised. Even so, Veil2's session management functions will usually load this data from the accessor_privileges_cache table. A few of the views shown do not contribute to session_privileges_v. These are developer views, aimed at providing data for development and debugging. Although all of Veil2's views may be replaced by user-supplied versions, the following views are expected to be. These views are expected to directly query user-provided tables which will be part of the set of data being protected by Veil2. These views do not directly contribute to Veil2 functionality. They exist to help developers in visuallizing and debugging data. These views are fundamental to the proper operation of Veil2. You may provide your own versions of these views if needed, but you should be aware that future versions of Veil2 may redefine and redevelop these views. Although your user-supplied views will take precedence, you run the risk of missing important improvements to performance and functionality, and more importantly, if the view semantics change, you risk breaking assumptions made by the Veil2 developers, which could have unforeseen consequences. That said, if you need to create a user-supplied version of one of these views, you are free to do so. If so, you should carefully review any revisions to Veil2 before applying the extension upgrade. You are also advised to discuss your needs with the Veil2 developers. Contact links can be found here. Materized views and caches are used to improve query performance. The trade-off for improved performance is that they need to be managed: whenever the data on which they depend is modified, they must be refreshed.