69.1. System Catalog Declaration Rules
The key part of a catalog header file is a C structure definition
describing the layout of each row of the catalog. This begins with
macro, which so far as the C compiler is
concerned is just shorthand for
Each field in the struct gives rise to a catalog column.
Fields can be annotated using the BKI property macros described
, for example to define a default value
for a field or mark it as nullable or not nullable.
line can also be annotated, with some
other BKI property macros described in
define other properties of the catalog as a whole, such as whether
it has OIDs (by default, it does).
The system catalog cache code (and most catalog-munging code in general)
assumes that the fixed-length portions of all system catalog tuples are
in fact present, because it maps this C struct declaration onto them.
Thus, all variable-length fields and nullable fields must be placed at
the end, and they cannot be accessed as struct fields.
For example, if you tried to
to be NULL, it would fail when some piece of code tried to reference
, because that follows
). This would result in
random errors or even segmentation violations.
As a partial guard against this type of error, variable-length or
nullable fields should not be made directly visible to the C compiler.
This is accomplished by wrapping them in
is a symbol that is never defined).
This prevents C code from carelessly trying to access fields that might
not be there or might be at some other offset.
As an independent guard against creating incorrect rows, we
require all columns that should be non-nullable to be marked so
. The bootstrap code will
automatically mark catalog columns as
if they are fixed-width and are not preceded by any nullable column.
Where this rule is inadequate, you can force correct marking by using
annotations as needed. But note
constraints are only enforced in the
executor, not against tuples that are generated by random C code,
so care is still needed when manually creating or updating catalog rows.
Frontend code should not include any
catalog header file, as these files may contain C code that won't compile
outside the backend. (Typically, that happens because these files also
contain declarations for functions
Instead, frontend code may include the corresponding
header, which will contain
s and any other data that might be of use
on the client side. If you want macros or other code in a catalog header
to be visible to frontend code, write
section to instruct
to copy that section
A few of the catalogs are so fundamental that they can't even be created
used for most catalogs, because that command needs to write information
into these catalogs to describe the new catalog. These are
catalogs, and defining one takes
a lot of extra work: you have to manually prepare appropriate entries for
them in the pre-loaded contents of
, and those entries will need to be
updated for subsequent changes to the catalog's structure.
(Bootstrap catalogs also need pre-loaded entries
handles that chore nowadays.)
Avoid making new catalogs be bootstrap catalogs if at all possible.