Module mz_catalog::builtin
source · Expand description
Built-in catalog items.
Builtins exist in the mz_catalog ambient schema. They are automatically
installed into the catalog when it is opened. Their definitions are not
persisted in the catalog, but hardcoded in this module. This makes it easy
to add new builtins, or change the definition of existing builtins, in new
versions of Materialize.
Builtin’s names, columns, and types are part of the stable API of Materialize. Be careful to maintain backwards compatibility when changing definitions of existing builtins!
More information about builtin system tables and types can be found in https://materialize.com/docs/sql/system-catalog/.
Modules§
Structs§
- Note: When creating a built-in index, it’s usually best to choose a key that has only one component. For example, if you created an index
ON mz_internal.mz_object_lifetimes (id, object_type), then this index couldn’t be used for a lookup forWHERE object_type = ..., and neither for joins keyed on justid. See https://materialize.com/docs/transform-data/optimization/#matching-multi-column-indexes-to-multi-column-where-clauses
Enums§
- Allows tests to inject arbitrary amounts of whitespace to forcibly change the fingerprint and trigger a builtin migration.
Constants§
- This role is like
MZ_MONITOR_ROLE, but can only query the redacted versions of the objects. - This role can
SELECTfrom various query history objects, e.g.mz_prepared_statement_history. - A sentinel used in place of a fingerprint that indicates that a builtin object is runtime alterable. Runtime alterable objects don’t have meaningful fingerprints because they may have been intentionally changed by the user after creation.
Statics§
- List of all builtin objects sorted topologically by dependency.
- Keys are builtin object description, values are the builtin index when sorted by dependency and the builtin itself.
- Traces the blue/green deployment lineage in the audit log to determine all cluster IDs that are logically the same cluster. cluster_id: The ID of a cluster. current_deployment_cluster_id: The cluster ID of the last cluster in cluster_id’s blue/green lineage. cluster_name: The name of the cluster. The approach taken is as follows. First, find all extant clusters and add them to the result set. Per cluster, we do the following:
- This view is used to display the cluster utilization over 14 days bucketed by 8 hours. It’s specifically for the Console’s environment overview page to speed up load times
- DEPRECATED and scheduled for removal! Use
mz_frontiersinstead. - PostgreSQL-specific metadata about types that doesn’t make sense to expose in the
mz_typestable as part of our public, stable API. - Peeled version of
PG_ATTRDEF: - Peeled version of
PG_ATTRIBUTE: - Peeled version of
PG_CLASS: - Note: Databases, Roles, Clusters, Cluster Replicas, Secrets, and Connections are excluded from this view for Postgres compatibility. Specifically, there is no classoid for these objects, which is required for this view.
- Peeled version of
PG_DESCRIPTION: - Peeled version of
PG_NAMESPACE: - Peeled version of
PG_TYPE:
Traits§
- Uniquely identifies the definition of a builtin object.