每个包含手动创建的初始数据（有些不包含）的目录都有一个对应的 .dat 文件，该文件以可编辑的格式包含其初始数据。
每个 .dat 文件都包含 Perl 数据结构字面量，这些字面量会被简单地 `eval` 来生成一个内存中的数据结构，该结构由一个哈希引用数组组成，每个哈希引用代表一行目录。对 `pg_database.dat` 的一个稍微修改过的摘录将演示关键特性。
[
# A comment could appear here.
{ oid => '1', oid_symbol => 'Template1DbOid',
descr => 'database\'s default template',
datname => 'template1', encoding => 'ENCODING',
datlocprovider => 'LOCALE_PROVIDER', datistemplate => 't',
datallowconn => 't', dathasloginevt => 'f', datconnlimit => '-1', datfrozenxid => '0',
datminmxid => '1', dattablespace => 'pg_default', datcollate => 'LC_COLLATE',
datctype => 'LC_CTYPE', datlocale => 'DATLOCALE', datacl => '_null_' },
]
需要注意的点
整体文件布局是：左方括号，一个或多个大括号集合（每个代表一行目录），右方括号。在每个闭合的大括号后写一个逗号。
在每个目录行内，写入逗号分隔的 键 => 值 对。允许的 键 是目录列的名称，加上元数据键 oid、oid_symbol、array_type_oid 和 descr。（oid 和 oid_symbol 的使用在下面 第 68.2.2 节 中描述，而 array_type_oid 在下面 第 68.2.4 节 中描述。 descr 为对象提供一个描述字符串，该字符串将被插入到 pg_description 或 pg_shdescription 中。）虽然元数据键是可选的，但必须提供目录定义的所有列，除非目录的 .h 文件为该列指定了默认值。（在上例中，datdba 字段已被省略，因为 pg_database.h 为其提供了合适的默认值。）
所有值都必须用单引号括起来。使用反斜杠转义值内的单引号。用作数据的反斜杠可以（但不必）加倍；这遵循 Perl 对简单引号字面量的规则。请注意，用作数据的反斜杠将被引导程序扫描器视为转义字符，规则与转义字符串常量相同（参见 第 4.1.2.2 节）；例如，\t 会转换为制表符。如果您确实想要一个反斜杠作为数据，您将需要写四个反斜杠：Perl 会剥离两个，留下 \\ 让引导程序扫描器看到。
空值用 _null_ 表示。（请注意，没有办法创建仅由该字符串组成的值。）
注释以 # 开头，并且必须独占一行。
字段值如果是其他目录条目的 OID，则应使用符号名称而不是实际的数字 OID 来表示。（在上例中，dattablespace 包含此类引用。）这在下面 第 68.2.3 节 中进行了描述。
由于哈希是无序的数据结构，字段顺序和行布局在语义上并不重要。但是，为了保持一致的外观，我们设定了一些由格式化脚本 reformat_dat_file.pl 应用的规则。
在大括号对之间，元数据字段 oid、oid_symbol、array_type_oid 和 descr（如果存在）先出现，按此顺序，然后是目录自身的字段，按其定义的顺序出现。
根据需要插入换行符以将行长度限制在 80 个字符（如果可能）。元数据字段和常规字段之间也会插入换行符。
如果目录的 .h 文件为某个列指定了默认值，并且某个数据条目具有相同的值，则 reformat_dat_file.pl 将在数据文件中省略它。这保持了数据表示的紧凑性。
reformat_dat_file.pl 按原样保留空行和注释行。
建议在提交目录数据补丁之前运行 reformat_dat_file.pl。为了方便起见，您可以简单地切换到 src/include/catalog/ 目录并运行 make reformat-dat-files。
如果您想添加一种新的数据表示压缩方法，您必须在 reformat_dat_file.pl 中实现它，并教 Catalog::ParseData() 如何将数据扩展回完整表示。
初始数据中出现的目录行可以通过写入 oid => 元数据字段来赋予手动分配的 OID。此外，如果分配了 OID，可以通过写入 nnnnoid_symbol => 元数据字段来为此 OID 创建一个 C 宏。name
预加载的目录行必须具有预先分配的 OID，如果其他预加载行中存在对它们的 OID 引用。如果行的 OID 需要从 C 代码中引用，也需要预先分配的 OID。如果以上两种情况都不适用，则可以省略 oid 元数据字段，在这种情况下，引导代码会自动分配一个 OID。实际上，我们通常会为给定目录中所有或所有预加载行预先分配 OID，即使只有其中一些实际上被交叉引用。
在 C 代码中写入任何 OID 的实际数值被认为是非常不好的做法；始终使用宏。对 pg_proc OID 的直接引用足够常见，以至于有一个特殊的机制来自动创建必要的宏；请参阅 src/backend/utils/Gen_fmgrtab.pl。类似地——但由于历史原因，做法不同——有一个自动方法用于为 pg_type OID 创建宏。oid_symbol 条目因此在这两个目录中不是必需的。同样，系统目录和索引的 pg_class OID 的宏也是自动设置的。对于所有其他系统目录，您必须通过 oid_symbol 条目手动指定您需要的任何宏。
要查找新预加载行的可用 OID，请运行脚本 src/include/catalog/unused_oids。它会打印未使用的 OID 的范围（例如，输出行 45-900 表示 OID 45 到 900 尚未分配）。目前，OID 1-9999 保留用于手动分配；unused_oids 脚本只是查看目录头文件和 .dat 文件，查看哪些 OID 未出现。您还可以使用 duplicate_oids 脚本检查错误。（genbki.pl 会为任何没有手动分配 OID 的行分配 OID，并且还会在编译时检测到重复的 OID。）
当为预计不会立即提交的补丁选择 OID 时，最佳实践是使用一组大致连续的 OID，以 8000-9999 范围内的某个随机选择开始。这最大限度地降低了与其他正在并行开发的补丁发生 OID 冲突的风险。为了将 8000-9999 范围保留用于开发目的，在补丁已提交到主 git 存储库后，其 OID 应重新编号到该范围以下的可用空间。通常，这将在每个开发周期结束时完成，同时将该周期中提交的所有补丁消耗的 OID 移动。可以使用 renumber_oids.pl 脚本来实现此目的。如果发现未提交的补丁与最近提交的补丁存在 OID 冲突，renumber_oids.pl 也可用于从该情况中恢复。
由于这种可能重新编号补丁分配的 OID 的约定，因此补丁分配的 OID 在补丁被包含在官方发行版中之前不应被视为稳定。但是，一旦发布，我们不会更改手动分配的对象 OID，因为这会产生各种兼容性问题。
如果 genbki.pl 需要为没有手动分配 OID 的目录条目分配 OID，它将使用 10000-11999 范围内的值。服务器的 OID 计数器在引导运行开始时设置为 10000，以便在引导处理过程中即时创建的任何对象也获得此范围内的 OID。（通常的 OID 分配机制负责防止任何冲突。）
OID 小于 FirstUnpinnedObjectId (12000) 的对象被视为“固定”（“pinned”），阻止其被删除。（有一些小的例外，这些例外已硬编码在 IsPinnedObject() 中。）initdb 在准备创建未固定对象时，会尽快将 OID 计数器强制提高到 FirstUnpinnedObjectId。因此，在 initdb 的后期阶段创建的对象（例如，在运行 information_schema.sql 脚本时创建的对象）将不会被固定，而 genbki.pl 所知的所有对象都将被固定。
在正常数据库操作期间分配的 OID 被限制为 16384 或更高。这确保了 10000-16383 范围可用于由 genbki.pl 或在 initdb 期间自动分配的 OID。这些自动分配的 OID 不被认为是稳定的，并且可能因一个安装到另一个安装而不同。
原则上，一个初始目录行到另一个的交叉引用可以通过在引用字段中写入被引用行的预分配 OID 来实现。然而，这违反了项目政策，因为容易出错、难以阅读，并且在重新编号新分配的 OID 时容易损坏。因此，genbki.pl 提供了使用符号引用代替的机制。规则如下：
通过将 BKI_LOOKUP( 附加到列的定义来启用特定目录列中的符号引用，其中 lookuprule)lookuprule 是被引用目录的名称，例如 pg_proc。BKI_LOOKUP 可以附加到 Oid、regproc、oidvector 或 Oid[] 类型的列；在后两种情况下，它意味着对数组的每个元素执行查找。
将 BKI_LOOKUP(encoding) 附加到整数列以引用字符集编码也是允许的，这些字符集编码目前不表示为目录 OID，但它们的值集是 genbki.pl 已知的。
在某些目录列中，条目可以为零而不是有效的引用。如果允许，请写 BKI_LOOKUP_OPT 而不是 BKI_LOOKUP。然后您可以为条目写 0。（如果列声明为 regproc，您可以选择写 - 而不是 0。）除了这个特殊情况，BKI_LOOKUP 列中的所有条目都必须是符号引用。genbki.pl 会警告未识别的名称。
大多数类型的目录对象仅通过其名称来引用。请注意，类型名称必须与被引用的 pg_type 条目的 typname 完全匹配；您不能使用任何别名，例如 integer 代替 int4。
函数可以由其 proname 表示，如果它在 pg_proc.dat 条目中是唯一的（这类似于 regproc 输入）。否则，写成 proname(argtypename,argtypename,...)，就像 regprocedure 一样。参数类型名称必须与 pg_proc.dat 条目的 proargtypes 字段中的名称完全一致。不要插入任何空格。
运算符表示为 oprname(lefttype,righttype)，类型名称必须与 pg_operator.dat 条目的 oprleft 和 oprright 字段中的名称完全一致。（对于一元运算符的省略操作数，写 0。）
操作符类和操作符族的名称仅在访问方法内是唯一的，因此它们表示为 access_method_name/object_name。
在以上任何情况下，都没有提供模式限定的机制；在引导期间创建的所有对象都应位于 pg_catalog 模式下。
genbki.pl 在运行时解析所有符号引用，并将简单的数字 OID 放入生成的 BKI 文件中。因此，引导后端无需处理符号引用。
即使某个目录当前不需要查找，也建议使用 BKI_LOOKUP 或 BKI_LOOKUP_OPT 来标记 OID 引用列。这允许 genbki.pl 记录系统目录中存在的外键关系。这些信息用于回归测试以检查不正确的条目。另请参阅宏 DECLARE_FOREIGN_KEY、DECLARE_FOREIGN_KEY_OPT、DECLARE_ARRAY_FOREIGN_KEY 和 DECLARE_ARRAY_FOREIGN_KEY_OPT，它们用于声明 BKI_LOOKUP 无法处理的（通常是多列外键）复杂外键关系。
大多数标量数据类型应该有一个对应的数组类型（即，一个元素类型为标量类型、并通过标量类型的 pg_type 条目的 typarray 字段引用的标准 varlena 数组类型）。在大多数情况下，genbki.pl 能够自动生成数组类型的 pg_type 条目。
要使用此功能，只需在标量类型的 pg_type 条目中写入 array_type_oid => 元数据字段，指定用于数组类型的 OID。然后您可以省略 nnnntyparray 字段，因为它将自动填充为该 OID。
生成的数组类型的名称是标量类型的名称前面加上下划线。数组条目的其他字段从 pg_type.h 中的 BKI_ARRAY_DEFAULT( 注释中填充，如果没有，则从标量类型中复制。（对于 value)typalign 也有一个特殊情况。）然后，两个条目的 typelem 和 typarray 字段被设置为相互引用。
以下是一些关于在更新目录数据文件时执行常见任务的最简单方法的建议。
为目录添加带有默认值的列： 在头文件中添加列，并带有 BKI_DEFAULT( 注释。数据文件只需在需要非默认值的地方调整，通过添加字段到现有行。value)
为没有默认值的现有列添加默认值： 在头文件中添加 BKI_DEFAULT 注释，然后运行 make reformat-dat-files 以删除现在多余的字段条目。
删除列，无论是否有默认值： 从头文件中删除列，然后运行 make reformat-dat-files 以删除现在无用的字段条目。
更改或删除现有默认值： 您不能仅更改头文件，因为这会导致当前数据被错误解释。首先运行 make expand-dat-files 将所有默认值显式插入到数据文件中，然后更改或删除 BKI_DEFAULT 注释，然后再次运行 make reformat-dat-files 以删除多余的字段。
临时批量编辑： reformat_dat_file.pl 可用于执行多种批量更改。查找其块注释，显示可以插入一次性代码的位置。在下面的示例中，我们将 pg_proc 中的两个布尔字段合并为一个 char 字段。
在 pg_proc.h 中添加新列（带默认值）。
+ /* see PROKIND_ categories below */ + char prokind BKI_DEFAULT(f);
创建一个基于 reformat_dat_file.pl 的新脚本，以即时插入适当的值。
- # At this point we have the full row in memory as a hash
- # and can do any operations we want. As written, it only
- # removes default values, but this script can be adapted to
- # do one-off bulk-editing.
+ # One-off change to migrate to prokind
+ # Default has already been filled in by now, so change to other
+ # values as appropriate
+ if ($values{proisagg} eq 't')
+ {
+ $values{prokind} = 'a';
+ }
+ elsif ($values{proiswindow} eq 't')
+ {
+ $values{prokind} = 'w';
+ }
运行新脚本。
$ cd src/include/catalog $ perl rewrite_dat_with_prokind.pl pg_proc.dat
此时 pg_proc.dat 包含所有三个列：prokind、proisagg 和 proiswindow，尽管它们只出现在具有非默认值的行中。
从 pg_proc.h 中删除旧列。
- /* is it an aggregate? */ - bool proisagg BKI_DEFAULT(f); - - /* is it a window function? */ - bool proiswindow BKI_DEFAULT(f);
最后，运行 make reformat-dat-files 以从 pg_proc.dat 中删除无用的旧条目。
有关用于批量编辑的脚本的更多示例，请参阅此消息附带的 convert_oid2name.pl 和 remove_pg_type_oid_symbols.pl：https://postgresql.ac.cn/message-id/CAJVSVGVX8gXnPm+Xa=DxR7kFYprcQ1tNcCT5D0O3ShfnM6jehA@mail.gmail.com
如果您在文档中看到任何不正确、与您对特定功能的使用经验不符或需要进一步说明的内容，请使用 此表单 报告文档问题。