Module pg 

pg_catalog, as read models over the schema the program already derives.

docs/23-incremental-views-report.md §23.19 held this open as “the correct long-run answer is a small read-only emulation of pg_class and friends”, and docs/08’s Phase 3 exit row carried it as the one thing a DBA still could not do: psql’s \d is a join over four catalogue relations, and those relations did not exist.

What this is

Every relation here is a crate::read::Table like any other, with a crate::read::Source::Pg saying where its rows come from — which is this module, from the Schema the compiler derived. So \d is answered by the same parser, the same crate::plan::Op::Join and the same scan that answer select * from todos, and there is no branch anywhere in beck_rt::pgwire that knows what a backslash command is. A catalogue that were a special case in the wire protocol would be a second query path to keep true; this one cannot disagree with the schema because it is the schema, read through a different set of column names.

What it is not

It is not PostgreSQL’s catalogue. There are no indexes, no constraints, no triggers, no sequences, no functions and no roles, because a read model has none of those things — so the relations that would describe them are here with their columns and no rows, which is the true answer rather than an absent one: \d todos asks about policies and publications on its way to printing a table, and “none” is what it needs to hear.

A relation that is not here at all is refused by name (Rel::missing), because a client that is told “there is no pg_catalog.pg_proc” knows what happened and a client handed an empty answer does not.

The four decisions in the rows

• Every read model is relkind = 'r' — an ordinary table. docs/05 §5.3’s promise is that a tool “sees materialized views as ordinary tables”, and a maintained arrangement answered as 'm' would send psql looking for a view definition this has no SQL to give it. What a table is derived from is in Schema::CATALOGUE, which is the table that answers that question.
• One namespace for the program, one for the catalogue. The read models are in public and these relations are in pg_catalog, which is what makes \d list the program’s tables and not its own: psql filters on nspname <> 'pg_catalog', and that filter has to have something to filter.
• The oids are positions, not identities. A relation’s oid is its index in a list that is built from the schema and cannot change while the process runs. Nothing persists one.
• Owner and access method are constants, because there is nobody to own a read model and no index to choose a method for.

Every column psql names is here; a column it does not name is not, so this file is short for the same reason the SQL is a subset.

Enums

Rel

One relation of the emulated catalogue.

Constants

ALL

Every relation, in the order relations builds them and therefore in oid order.

CATALOG

The namespace these relations are in, and the one psql hides from \d.

OWNER

The one role every read model is owned by. There is no authentication on this port (adr/0020), so there is no user to be the owner and this is the name pg_get_userbyid answers with.

PUBLIC

The namespace a program’s read models are in.

Functions

call

A pg_catalog function, applied to the arguments a row produced.

relations

The catalogue’s relations as tables, in oid order.

rows

One relation’s rows, derived from the schema.