About View Storage in LightDB-A Database

A view is similar to a table, both are relations - that is “something with columns”. All such objects are stored in the catalog table pg_class. These are the general differences:

• A view has no data files (because it holds no data).
• The value of pg_class.relkind for a view is v rather than r.

• A view has an ON SELECT query rewrite rule called _RETURN.

  The rewrite rule contains the definition of the view and is stored in the ev_action column of the pg_rewrite catalog table.

For more technical information about views, see the PostgreSQL documentation about Views and the Rule System.

Also, a view definition is not stored as a string, but in the form of a query parse tree. Views are parsed when they are created, which has several consequences:

• Object names are resolved during CREATE VIEW, so the current setting of search_path affects the view definition.
• Objects are referred to by their internal immutable object ID rather than by their name. Consequently, renaming an object or column referenced in a view definition can be performed without dropping the view.
• LightDB-A Database can determine exactly which objects are used in the view definition, so it can add dependencies on them.

Note that the way LightDB-A Database handles views is quite different from the way LightDB-A Database handles functions: function bodies are stored as strings and are not parsed when they are created. Consequently, LightDB-A Database does not know on which objects a given function depends.

Where View Dependency Information is Stored

These system catalog tables contain the information used to determine the tables on which a view depends.

• pg_class - object information including tables and views. The relkind column describes the type of object.
• pg_depend - object dependency information for database-specific (non-shared) objects.
• pg_rewrite - rewrite rules for tables and views.
• pg_attribute - information about table columns.
• pg_namespace - information about schemas (namespaces).

It is important to note that there is no direct dependency of a view on the objects it uses: the dependent object is actually the view’s rewrite rule. That adds another layer of indirection to view dependency information.