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§
Constants§
- This role is like
MZ_MONITOR_ROLE
, but can only query the redacted versions of the objects. - This role can
SELECT
from various query history objects, e.g.mz_prepared_statement_history
.
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.
- DEPRECATED and scheduled for removal! Use
mz_frontiers
instead. - PostgreSQL-specific metadata about types that doesn’t make sense to expose in the
mz_types
table as part of our public, stable API. - 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.
- Allows tests to inject arbitrary amounts of whitespace to forcibly change the fingerprint and trigger a builtin migration. Ideally this would be guarded by a
#[cfg(test)]
but unfortunately, the builtin migrations are in a different crate and would not be able to modify this value. There is an open issue to move builtin migrations to this crate: https://github.com/MaterializeInc/materialize/issues/22593
Traits§
- Uniquely identifies the definition of a builtin object.