Expand description
Text renderings of regproc values.
PostgreSQL renders a regproc in text format through regprocout, which
resolves the OID to the function’s name. Materialize has no
CREATE FUNCTION, so every function is a builtin and the OID to name
mapping is fixed when the binary is built. That is what makes a static
table viable: the text encoder has no catalog access and cannot gain any,
because the catalog crates depend on mz-pgrepr rather than the reverse,
and some encode paths run in clusterd, which has no catalog at all.
NAMES is derived from Materialize’s builtin function registry, reached
through mz_catalog::builtin::BUILTINS::funcs(), which is the authoritative
definition of every function OID. mz_catalog::builtin’s
test_regproc_names_match_builtin_functions recomputes the whole table from
that registry and fails when the two have drifted, so do not hand-edit
entries here. Add the function to the registry, then regenerate the table:
REWRITE=1 cargo test -p mz-catalog test_regproc_names_match_builtin_functionsThe OIDs are not invented by Materialize wherever PostgreSQL already assigns
one. mz_sql::func’s PG_CATALOG_BUILTINS records that its literal OIDs
were read out of a PostgreSQL 13 pg_proc, and points at
https://github.com/postgres/postgres/blob/master/src/include/catalog/pg_proc.dat
for the same values. Everything else draws from crate::oid, which carves
out FIRST_UNPINNED_OID upward for functions PostgreSQL ships without a
pinned OID, and FIRST_MATERIALIZE_OID upward for functions that exist only
in Materialize.
Enums§
- Name
Lookup Error - Why
oidcould not resolve a name.
Constants§
- NAMES
- Every builtin function OID paired with the text
regprocrenders it as, sorted by OID.