Each catalog that has any manually-created initial data (some do not)
has a corresponding <literal>.dat</literal> file that contains its
initial data in an editable format.
手動で生成した初期データを持つ（いくつかのものは持っていません）各々のカタログには、編集可能なデータ形式の初期データを含み、対応する.datファイルがあります。
Each <literal>.dat</literal> file contains Perl data structure literals
that are simply eval'd to produce an in-memory data structure consisting
of an array of hash references, one per catalog row.
A slightly modified excerpt from <filename>pg_database.dat</filename>
will demonstrate the key features:
個々の.datファイルにはPerlのデータ構造文字列が含まれます。
それらは単に評価されることによって1個がカタログの1行に対応するハッシュ参照の配列を含むメモリ上のデータ構造を生成します。
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_' },
]
Points to note: 特筆すべきポイント：
The overall file layout is: open square bracket, one or more sets of curly braces each of which represents a catalog row, close square bracket. Write a comma after each closing curly brace. 全体的なファイルレイアウトは次のようになります。 開き大括弧、カタログの行を表現する一つ以上の中括弧、閉じ大括弧。 各々の閉じ中括弧の後にはカンマを書きます。
Within each catalog row, write comma-separated
<replaceable>key</replaceable> <literal>=></literal>
<replaceable>value</replaceable> pairs. The
allowed <replaceable>key</replaceable>s are the names of the catalog's
columns, plus the metadata keys <literal>oid</literal>,
<literal>oid_symbol</literal>,
<literal>array_type_oid</literal>, and <literal>descr</literal>.
(The use of <literal>oid</literal> and <literal>oid_symbol</literal>
is described in <xref linkend="system-catalog-oid-assignment"/> below,
while <literal>array_type_oid</literal> is described in
<xref linkend="system-catalog-auto-array-types"/>.
<literal>descr</literal> supplies a description string for the object,
which will be inserted into <structname>pg_description</structname>
or <structname>pg_shdescription</structname> as appropriate.)
While the metadata keys are optional, the catalog's defined columns
must all be provided, except when the catalog's <literal>.h</literal>
file specifies a default value for the column.
(In the example above, the <structfield>datdba</structfield> field has
been omitted because <filename>pg_database.h</filename> supplies a
suitable default value for it.)
各々のカタログ行にカンマ区切りでkey=>valueペアを書きます。
記述可能なkeyは、カタログの列に加えてメタデータキーであるoid、oid_symbol、array_type_oid、descrです。
（oidとoid_symbolの使い方は後述の67.2.2で説明されていて、一方、array_type_oidは67.2.4で説明されています。
descrはオブジェクトの説明文字列に使用し、pg_descriptionかpg_shdescriptionの適切な方に挿入されます。）
メタデータキーは省略可能であるのに対し、カタログの.hファイルが列のデフォルト値を指定する場合を除いてカタログの定義済み列はすべて提供されなければなりません。
（上記の例ではpg_database.hが適切なデフォルト値を供するのでdatdbaフィールドは省略されました。）
All values must be single-quoted. Escape single quotes used within a
value with a backslash. Backslashes meant as data can, but need not,
be doubled; this follows Perl's rules for simple quoted literals.
Note that backslashes appearing as data will be treated as escapes by
the bootstrap scanner, according to the same rules as for escape string
constants (see <xref linkend="sql-syntax-strings-escape"/>); for
example <literal>\t</literal> converts to a tab character. If you
actually want a backslash in the final value, you will need to write
four of them: Perl strips two, leaving <literal>\\</literal> for the
bootstrap scanner to see.
すべての値は単一引用符で囲まなければなりません。
値中の単一引用符はバックスラッシュでエスケープします。
データを意味するバックスラッシュは二重にできますが、必須ではありません。
これはPerlの単純な単一引用符で引用されたリテラルに関するルールに基づいています。
データとして使われるバックスラッシュは、エスケープ文字列定数（4.1.2.2参照）と同じルールに基づき、ブートストラップスキャナはエスケープと解釈することに注意してください。
たとえば\tはタブへと変換されます。
最終的な値としてバックスラッシュを使用したい場合は、4つ書く必要があります。
Perlが２つ削除し、ブートストラップスキャナが認識するために\\が残ります。
Null values are represented by <literal>_null_</literal>.
(Note that there is no way to create a value that is just that
string.)
NULL値は_null_で表します。
（それと同じ文字列を作る方法はないことに注意してください。）
Comments are preceded by <literal>#</literal>, and must be on their
own lines.
コメントは#を前に置いてください。また同じ行上に置かなければなりません。
Field values that are OIDs of other catalog entries should be
represented by symbolic names rather than actual numeric OIDs.
(In the example above, <structfield>dattablespace</structfield>
contains such a reference.)
This is described in <xref linkend="system-catalog-oid-references"/>
below.
他のカタログエントリのOIDであるフィールド値は、実際の数値のOIDではなくシンボル名で記述されるべきです。
（上記の例ではdattablespaceがこのような参照を含みます。）
これは後述の67.2.3で説明します。
Since hashes are unordered data structures, field order and line
layout aren't semantically significant. However, to maintain a
consistent appearance, we set a few rules that are applied by the
formatting script <filename>reformat_dat_file.pl</filename>:
ハッシュは順序付けられないデータ構造なので、フィールドの順や行の配置には重要な意味はありません。
しかし、見た目を統一するために、フォーマットスクリプトreformat_dat_file.plが適用される少数のルールを設定しました。
Within each pair of curly braces, the metadata
fields <literal>oid</literal>, <literal>oid_symbol</literal>,
<literal>array_type_oid</literal>, and <literal>descr</literal>
(if present) come first, in that order, then the catalog's own
fields appear in their defined order.
中括弧のペアの中で、メタデータフィールドのoid、oid_symbol、array_type_oid、および、（もし存在するなら）descrがこの順で最初に来ます。
そして、定義された順にカタログ自身のフィールドが現れます。
Newlines are inserted between fields as needed to limit line length to 80 characters, if possible. A newline is also inserted between the metadata fields and the regular fields. 可能ならば、行の長さを80文字に制限するために、必要に応じてフィールドの間に改行を挿入します。 改行はメタデータフィールドと通常のフィールドの間にも挿入します。
If the catalog's <literal>.h</literal> file specifies a default
value for a column, and a data entry has that same
value, <filename>reformat_dat_file.pl</filename> will omit it from
the data file. This keeps the data representation compact.
カタログの.hファイルが列のデフォルト値を指定していて、データエントリが同じ値なら、reformat_dat_file.plはデータファイルからデータエントリを省略します。
これでデータ表現が小さくなります。
<filename>reformat_dat_file.pl</filename> preserves blank lines
and comment lines as-is.
reformat_dat_file.plは空白行とコメント行をそのまま維持します。
It's recommended to run <filename>reformat_dat_file.pl</filename>
before submitting catalog data patches. For convenience, you can
simply change to <filename>src/include/catalog/</filename> and
run <literal>make reformat-dat-files</literal>.
カタログデータパッチを投稿する前に、reformat_dat_file.plを実行することをお勧めします。
便利さのために、単にsrc/include/catalog/に変更を加えてmake reformat-dat-filesを実行することができます。
If you want to add a new method of making the data representation
smaller, you must implement it
in <filename>reformat_dat_file.pl</filename> and also
teach <function>Catalog::ParseData()</function> how to expand the
data back into the full representation.
データ表現をより小さくする新しい方法を付け加えたいのであれば、reformat_dat_file.plで実装し、また
データを完全な表現に戻す方法をCatalog::ParseData()に指示しなければなりません。
A catalog row appearing in the initial data can be given a
manually-assigned OID by writing an <literal>oid
=> <replaceable>nnnn</replaceable></literal> metadata field.
Furthermore, if an OID is assigned, a C macro for that OID can be
created by writing an <literal>oid_symbol
=> <replaceable>name</replaceable></literal> metadata field.
初期データに現れるカタログ行にはoid=> メタデータフィールドを書くことで手動で割り当てたOIDを与えることができます。
それだけでなく、OIDを割り当てられたならば、nnnnoid_symbol => メタデータフィールドを書くことでそのOID用のCマクロを作ることができます。
name
Pre-loaded catalog rows must have preassigned OIDs if there are OID
references to them in other pre-loaded rows. A preassigned OID is
also needed if the row's OID must be referenced from C code.
If neither case applies, the <literal>oid</literal> metadata field can
be omitted, in which case the bootstrap code assigns an OID
automatically.
In practice we usually preassign OIDs for all or none of the pre-loaded
rows in a given catalog, even if only some of them are actually
cross-referenced.
他のプリロードカタログ行の中にそのOIDへの参照がある場合には、プリロードカタログ行は割当済みのOIDを持たなければなりません。
Cコードから行OIDが参照されるときにも割当済みのOIDは必要です。
どちらも当てはまらない場合は、oidメタデータフィールドは省略可能です。
その場合、ブートストラップコードが自動的にOIDを割り当てます。
実用的には、カタログの一部のみが実際に相互参照されている場合でも、与えられたプリロードカタログ行のOIDをすべて割当済みにするか、一つも割当済みにしないかのどちらかに通常します。
Writing the actual numeric value of any OID in C code is considered
very bad form; always use a macro, instead. Direct references
to <structname>pg_proc</structname> OIDs are common enough that there's
a special mechanism to create the necessary macros automatically;
see <filename>src/backend/utils/Gen_fmgrtab.pl</filename>. Similarly
— but, for historical reasons, not done the same way —
there's an automatic method for creating macros
for <structname>pg_type</structname>
OIDs. <literal>oid_symbol</literal> entries are therefore not
necessary in those two catalogs. Likewise, macros for
the <structname>pg_class</structname> OIDs of system catalogs and
indexes are set up automatically. For all other system catalogs, you
have to manually specify any macros you need
via <literal>oid_symbol</literal> entries.
Cコード中でOIDの実際の数値を書くのは非常に良くないと考えられます。
pg_procを直接参照するのは普通のことなので、自動的に必要なマクロを生成する特別な仕掛けがあります。
src/backend/utils/Gen_fmgrtab.plを見てください。
歴史的理由により、似ていはいますが同じではない方法によるpg_type OID用のマクロを自動生成する仕組みがあります。
ですから、oid_symbolエントリはこれらの２つのカタログに必ずしも存在しなければならないというわけではありません。
同様に、pg_classシステムカタログのOIDとインデックスマクロは自動的に設定されます。
他のすべてのシステムカタログでは、oid_symbolを使って必要なマクロを手動で指定しなければなりません。
To find an available OID for a new pre-loaded row, run the
script <filename>src/include/catalog/unused_oids</filename>.
It prints inclusive ranges of unused OIDs (e.g., the output
line <literal>45-900</literal> means OIDs 45 through 900 have not been
allocated yet). Currently, OIDs 1–9999 are reserved for manual
assignment; the <filename>unused_oids</filename> script simply looks
through the catalog headers and <filename>.dat</filename> files
to see which ones do not appear. You can also use
the <filename>duplicate_oids</filename> script to check for mistakes.
(<filename>genbki.pl</filename> will assign OIDs for any rows that
didn't get one hand-assigned to them, and it will also detect duplicate
OIDs at compile time.)
新しいプリロード行のために利用可能なOIDを見つけるには、src/include/catalog/unused_oidsスクリプトを実行してください。
未使用のOIDの範囲が表示されます。
（たとえば、出力行45-900はOIDs 45から900が利用されていないことを示します。）
今の所OID 1–9999 は手動での割当のために予約されています。
unused_oidsスクリプトは、単にカタログヘッダと.datを見てそこに出現していないOIDを探しているだけです。
間違い見つけるためにduplicate_oidsを利用することもできます。
（genbki.plは手動アサインされていない全ての行にOIDを割り当て、また、コンパイル時に重複OIDを検出します。）
When choosing OIDs for a patch that is not expected to be committed
immediately, best practice is to use a group of more-or-less
consecutive OIDs starting with some random choice in the range
8000—9999. This minimizes the risk of OID collisions with other
patches being developed concurrently. To keep the 8000—9999
range free for development purposes, after a patch has been committed
to the master git repository its OIDs should be renumbered into
available space below that range. Typically, this will be done
near the end of each development cycle, moving all OIDs consumed by
patches committed in that cycle at the same time. The script
<filename>renumber_oids.pl</filename> can be used for this purpose.
If an uncommitted patch is found to have OID conflicts with some
recently-committed patch, <filename>renumber_oids.pl</filename> may
also be useful for recovering from that situation.
即座にコミットされるとは期待できないパッチ用にOIDを選ぶときの最良の手法は、8000—9999の範囲でランダムに選択したところから始まるおおむね連続したOIDのグループを使うことです。
これは同時に開発されている他のパッチとのOID衝突の危険を最小化します。
8000—9999の範囲を開発目的に空けておくため、パッチがマスタgitリポジトリにコミットされた後、そのOIDはこの範囲の下位の使用可能な場所に番号の振り直しをすべきです。
通例これは各開発サイクルの終わり近くに行われ、同時にそのサイクルでコミットされたパッチで消費された全てのOIDを移動するでしょう。
スクリプトrenumber_oids.plはこの目的に使用できます。
コミットされていないパッチが最近コミットされたパッチとOID衝突していることに気づいた場合に、このような状況から回復するのにもrenumber_oids.plがおそらく役立つでしょう。
Because of this convention of possibly renumbering OIDs assigned by patches, the OIDs assigned by a patch should not be considered stable until the patch has been included in an official release. We do not change manually-assigned object OIDs once released, however, as that would create assorted compatibility problems. パッチに割り当てられたOIDを番号付け替えすることがあるこの慣習のため、パッチに割り当てられたOIDはそのパッチが正式リリースに含まれるまでは永続的と考えるべきではありません。 さまざまな互換性の問題を生み出すかもしれないため、一度リリースされた手動でアサインされたオブジェクトのOIDは変更しません。
If <filename>genbki.pl</filename> needs to assign an OID to a catalog
entry that does not have a manually-assigned OID, it will use a value in
the range 10000—11999. The server's OID counter is set to 10000
at the start of a bootstrap run, so that any objects created on-the-fly
during bootstrap processing also receive OIDs in this range. (The
usual OID assignment mechanism takes care of preventing any conflicts.)
genbki.plは、手動アサインされたOIDを持たないカタログエントリにOIDを割り当てる必要がある場合、10000—11999範囲の値を使います。
ブートストラップの実行開始時にその場で作成されるオブジェクトもこの範囲のOIDが設定されるように、ブートストラップ実行開始の際にはサーバのOIDカウンタは10000に設定されます。（通常のOID割当機構は、衝突を回避するように調整を行います。）
Objects with OIDs below <symbol>FirstUnpinnedObjectId</symbol> (12000)
are considered <quote>pinned</quote>, preventing them from being
deleted. (There are a small number of exceptions, which are
hard-wired into <function>IsPinnedObject()</function>.)
<application>initdb</application> forces the OID counter up
to <symbol>FirstUnpinnedObjectId</symbol> as soon as it's ready to
create unpinned objects. Thus objects created during the later phases
of <application>initdb</application>, such as objects created while
running the <filename>information_schema.sql</filename> script, will
not be pinned, while all objects known
to <filename>genbki.pl</filename> will be.
FirstUnpinnedObjectId (12000)以下のOIDを持つオブジェクトは「固定」と見なされ、削除されません。
（IsPinnedObject()に固定されている少数の例外があります。）
initdbは、固定されていないオブジェクトを作成する準備ができるとすぐに、OIDカウンタをFirstUnpinnedObjectIdまで強制的に増加させます。
このため、information_schema.sqlスクリプトの実行中に作成されたオブジェクトなど、initdbの後半のフェーズで作成されたオブジェクトは固定されませんが、genbki.plで認識されているすべてのオブジェクトは固定されます。
OIDs assigned during normal database operation are constrained to be
16384 or higher. This ensures that the range 10000—16383 is free
for OIDs assigned automatically by <filename>genbki.pl</filename> or
during <application>initdb</application>. These
automatically-assigned OIDs are not considered stable, and may change
from one installation to another.
通常のデータベース操作で割り当てられたOIDは16384以上に限定されます。
これはgenbki.plやinitdb中に自動的に割り当てられたOIDに対して10000—16383の範囲が空いていること保証します。
これらの自動割り当てされたOIDは今後も変更がないとはいえず、あるインストレーションから他のインストレーションで変更されるかもしれません。
In principle, cross-references from one initial catalog row to another
could be written just by writing the preassigned OID of the referenced
row in the referencing field. However, that is against project
policy, because it is error-prone, hard to read, and subject to
breakage if a newly-assigned OID is renumbered. Therefore
<filename>genbki.pl</filename> provides mechanisms to write
symbolic references instead.
The rules are as follows:
原則としては、ある初期カタログ行から他への相互参照は、参照しているフィールドで参照されている行の事前割り当てされたOIDを書くことだけで記述できます。
しかしながら、間違いやすく、読みにくく、また、新たに割り当てられたOIDが番号付け直しされたときに破損しやすいため、これはプロジェクト方針に反します。
そのため、genbki.plが代わりにシンボル参照を記述する機構を提供しています。
そのルールは以下のとおりです。
Use of symbolic references is enabled in a particular catalog column
by attaching <literal>BKI_LOOKUP(<replaceable>lookuprule</replaceable>)</literal>
to the column's definition, where <replaceable>lookuprule</replaceable>
is the name of the referenced catalog, e.g., <literal>pg_proc</literal>.
<literal>BKI_LOOKUP</literal> can be attached to columns of
type <type>Oid</type>, <type>regproc</type>, <type>oidvector</type>,
or <type>Oid[]</type>; in the latter two cases it implies performing a
lookup on each element of the array.
BKI_LOOKUP(を列の定義に加えることで、特定のカタログ列でのシンボル参照が利用可能になります。
ここでlookuprule)lookupruleは参照されているカタログ名で、例えばpg_procです。
BKI_LOOKUPを、Oid、regproc、oidvector、Oid[]の列に加えることができます。
最後の２つにおいては、配列の個々の要素を検索することを暗に意味します。
It's also permissible to attach <literal>BKI_LOOKUP(encoding)</literal>
to integer columns to reference character set encodings, which are
not currently represented as catalog OIDs, but have a set of values
known to <filename>genbki.pl</filename>.
文字セット符号化方式を参照する整数の列にBKI_LOOKUP(encoding)を加えることも許容されます。これは今のところカタログのOIDとして現れませんが、値の集合をgenbki.plに知らせます。
In some catalog columns, it's allowed for entries to be zero instead
of a valid reference. If this is allowed, write
<literal>BKI_LOOKUP_OPT</literal> instead
of <literal>BKI_LOOKUP</literal>. Then you can
write <literal>0</literal> for an entry. (If the column is
declared <type>regproc</type>, you can optionally
write <literal>-</literal> instead of <literal>0</literal>.)
Except for this special case, all entries in
a <literal>BKI_LOOKUP</literal> column must be symbolic references.
<filename>genbki.pl</filename> will warn about unrecognized names.
カタログ列の中には、エントリを有効な参照の代わりにゼロとすることが許されているものがあります。
これが許されているなら、BKI_LOOKUPの代わりにBKI_LOOKUP_OPTを書いてください。
そうすれば、エントリに0を書くことができます。
（列がregprocと宣言されている場合は、0の代わりに-と書くことができます。）
この特別な場合を除いて、BKI_LOOKUP列内のすべてのエントリはシンボル参照でなければなりません。
genbki.plは認識できない名前には警告を出します。
Most kinds of catalog objects are simply referenced by their names.
Note that type names must exactly match the
referenced <structname>pg_type</structname>
entry's <structfield>typname</structfield>; you do not get to use
any aliases such as <literal>integer</literal>
for <literal>int4</literal>.
たいていのカタログオブジェクト類は単純にその名前で参照されます。
型名は参照されているpg_typeのエントリのtypnameと正確に一致しなければならないことに注意してください。int4に対するintegerなどの別名は使えません。
A function can be represented by
its <structfield>proname</structfield>, if that is unique among
the <filename>pg_proc.dat</filename> entries (this works like regproc
input). Otherwise, write it
as <replaceable>proname(argtypename,argtypename,...)</replaceable>,
like regprocedure. The argument type names must be spelled exactly as
they are in the <filename>pg_proc.dat</filename> entry's
<structfield>proargtypes</structfield> field. Do not insert any
spaces.
それがpg_proc.dat内でユニークなら、関数はpronameで表現できます。
（regprocの入力はこのように働きます。）
そうでなければ、regprocedureのように、proname(argtypename,argtypename,...)と書いてください。
引数型名は正確にpg_proc.datエントリのproargtypesで指定しなければなりません。
空白は挿入しないでください。
Operators are represented
by <replaceable>oprname(lefttype,righttype)</replaceable>,
writing the type names exactly as they appear in
the <filename>pg_operator.dat</filename>
entry's <structfield>oprleft</structfield>
and <structfield>oprright</structfield> fields.
(Write <literal>0</literal> for the omitted operand of a unary
operator.)
演算子はoprname(lefttype,righttype)で表現します。
型名は正確にpg_operator.datエントリのoprleftフィールドとoprrightフィールドで記述します。
（省略された単項演算子のオペランドは0と書きます。）
The names of opclasses and opfamilies are only unique within an
access method, so they are represented
by <replaceable>access_method_name</replaceable><literal>/</literal><replaceable>object_name</replaceable>.
opclassesとopfamiliesの名前はアクセスメソッド内でのみユニークなので、access_method_name/object_nameで表します。
In none of these cases is there any provision for
schema-qualification; all objects created during bootstrap are
expected to be in the <literal>pg_catalog</literal> schema.
以上のいずれの場合にもスキーマ修飾の規定はありません。
ブートストラップ中に作成されるすべてのオブジェクトは、pg_catalogスキーマにあると期待されます。
<filename>genbki.pl</filename> resolves all symbolic references while it
runs, and puts simple numeric OIDs into the emitted BKI file. There is
therefore no need for the bootstrap backend to deal with symbolic
references.
genbki.plは実行中にすべてのシンボル参照を解決し、生成したBKIファイルの中に単純な数字のOIDを設定します。
ですから、ブートストラップバックエンドはシンボル参照にかかわる必要はありません。
It's desirable to mark OID reference columns
with <literal>BKI_LOOKUP</literal> or <literal>BKI_LOOKUP_OPT</literal>
even if the catalog has no initial data that requires lookup. This
allows <filename>genbki.pl</filename> to record the foreign key
relationships that exist in the system catalogs. That information is
used in the regression tests to check for incorrect entries. See also
the macros <literal>DECLARE_FOREIGN_KEY</literal>,
<literal>DECLARE_FOREIGN_KEY_OPT</literal>,
<literal>DECLARE_ARRAY_FOREIGN_KEY</literal>,
and <literal>DECLARE_ARRAY_FOREIGN_KEY_OPT</literal>, which are
used to declare foreign key relationships that are too complex
for <literal>BKI_LOOKUP</literal> (typically, multi-column foreign
keys).
カタログに検索の必要な初期データがなかったとしても、OID参照列にBKI_LOOKUPやBKI_LOOKUP_OPTの印を付けておくことが望ましいです。
これにより、genbki.plがシステムカタログ内に存在する外部キー関係を記録できるようになります。
その情報は間違ったエントリを確認するリグレッションテストで使われます。
マクロDECLARE_FOREIGN_KEY、DECLARE_FOREIGN_KEY_OPT、DECLARE_ARRAY_FOREIGN_KEY、DECLARE_ARRAY_FOREIGN_KEY_OPTも参照してください。BKI_LOOKUPには複雑すぎる外部キー関係（典型的には、複数列の外部キー）を宣言するのに使われます。
Most scalar data types should have a corresponding array type (that is,
a standard varlena array type whose element type is the scalar type, and
which is referenced by the <structfield>typarray</structfield> field of
the scalar type's <structname>pg_type</structname>
entry). <filename>genbki.pl</filename> is able to generate
the <structname>pg_type</structname> entry for the array type
automatically in most cases.
たいていのスカラデータ型は対応する配列型を持つはずです（すなわち、要素がスカラ型の標準varlena配列型で、スカラ型のpg_typeエントリのtyparrayフィールドから参照されているもの）。
genbki.plはたいていの場合に配列型に対するpg_typeエントリも自動的に生成できます。
To use this facility, just write an <literal>array_type_oid
=> <replaceable>nnnn</replaceable></literal> metadata field in the
scalar type's <structname>pg_type</structname> entry, specifying the OID
to use for the array type. You may then omit
the <structfield>typarray</structfield> field, since it will be filled
automatically with that OID.
この機能を使うには、スカラ型のpg_typeエントリにarray_type_oid => というメタデータフィールドを記述して、配列型に使用するOIDを指定します。
自動的にそのOIDが書かれるため、このときnnnntyparrayフィールドを省いてもよいです。
The generated array type's name is the scalar type's name with an
underscore prepended. The array entry's other fields are filled from
<literal>BKI_ARRAY_DEFAULT(<replaceable>value</replaceable>)</literal>
annotations in <filename>pg_type.h</filename>, or if there isn't one,
copied from the scalar type. (There's also a special case
for <structfield>typalign</structfield>.) Then
the <structfield>typelem</structfield>
and <structfield>typarray</structfield> fields of the two entries are
set to cross-reference each other.
生成された配列型の名前は、スカラ型の名前の手前にアンダースコアを付けたものです。
配列エントリの他のフィールドは、pg_type.hでBKI_ARRAY_DEFAULT(注釈から充当され、もし無ければスカラ型からコピーされます。
（value)typalignに対する特別な場合もあります。）
さらに両エントリのtypelemおよびtyparrayフィールドは相互参照するように設定されます。
Here are some suggestions about the easiest ways to perform common tasks when updating catalog data files. カタログデータファイルを更新する共通の作業を実施するためのもっとも簡単な方法の提案を示します。
<title>Add a new column with a default to a catalog:</title>
カタログにデフォルト付きの新しい列を追加する.
Add the column to the header file with
a <literal>BKI_DEFAULT(<replaceable>value</replaceable>)</literal>
annotation. The data file need only be adjusted by adding the field
in existing rows where a non-default value is needed.
BKI_DEFAULT(注釈付きでヘッダファイルに列を追加します。
非デフォルト値が必要な既存の行に対してのみフィールドを追加によるデータファイルの調整が必要です。
value)
<title>Add a default value to an existing column that doesn't have
one:</title>
デフォルト値を持たない既存の列にデフォルト値を追加する.
Add a <literal>BKI_DEFAULT</literal> annotation to the header file,
then run <literal>make reformat-dat-files</literal> to remove
now-redundant field entries.
BKI_DEFAULT注釈をヘッダファイルに追加し、冗長になったフィールドエントリを削除するためにmake reformat-dat-filesを実行します。
<title>Remove a column, whether it has a default or not:</title>
デフォルト値の有無にかかわらず、列を削除する.
Remove the column from the header, then run <literal>make
reformat-dat-files</literal> to remove now-useless field entries.
ヘッダから列を削除し、make reformat-dat-filesを実行して不要になったフィールドエントリを削除します。
<title>Change or remove an existing default value:</title>
既存のデフォルト値を変更もしくは削除する.
You cannot simply change the header file, since that will cause the
current data to be interpreted incorrectly. First run <literal>make
expand-dat-files</literal> to rewrite the data files with all
default values inserted explicitly, then change or remove
the <literal>BKI_DEFAULT</literal> annotation, then run <literal>make
reformat-dat-files</literal> to remove superfluous fields again.
現在のデータが正しく解釈されなくなるため、単にヘッダファイルを変更することはできません。
まずmake expand-dat-filesを実行し、すべてのデフォルト値が明示的に挿入されるようにデータファイルを書き換えます。
次にBKI_DEFAULT注釈を変更もしくは削除し、make reformat-dat-filesを実行して余分のフィールドを再び削除します。
<title>Ad-hoc bulk editing:</title>
特定の目的のための大量の編集:
<filename>reformat_dat_file.pl</filename> can be adapted to perform
many kinds of bulk changes. Look for its block comments showing where
one-off code can be inserted. In the following example, we are going
to consolidate two Boolean fields in <structname>pg_proc</structname>
into a char field:
reformat_dat_file.plを使って色々な大量の変更を実施できます。
一度限りのコードを挿入できることを示すブロックコメントを見つけます。
次の例では、pg_proc中の２つの論理値型フィールドを一つの文字フィールドに統合します。
Add the new column, with a default,
to <filename>pg_proc.h</filename>:
デフォルトがある新しい列をpg_proc.hに追加します。
+ /* see PROKIND_ categories below */ + char prokind BKI_DEFAULT(f);
Create a new script based on <filename>reformat_dat_file.pl</filename>
to insert appropriate values on-the-fly:
臨機応変に適当な値を挿入するために、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';
+ }
Run the new script: スクリプトを実行します。
$ cd src/include/catalog $ perl rewrite_dat_with_prokind.pl pg_proc.dat
At this point <filename>pg_proc.dat</filename> has all three
columns, <structfield>prokind</structfield>,
<structfield>proisagg</structfield>,
and <structfield>proiswindow</structfield>, though they will appear
only in rows where they have non-default values.
この時点でpg_proc.datにはprokind、proisagg、proiswindowのすべての3つの列がありますが、非デフォルト値を持つ行だけに表れます。
Remove the old columns from <filename>pg_proc.h</filename>:
pg_proc.hから古い列を削除します。
- /* is it an aggregate? */ - bool proisagg BKI_DEFAULT(f); - - /* is it a window function? */ - bool proiswindow BKI_DEFAULT(f);
Finally, run <literal>make reformat-dat-files</literal> to remove
the useless old entries from <filename>pg_proc.dat</filename>.
最後に、make reformat-dat-filesを実行してpg_proc.datから不要になった古いエントリを削除します。
For further examples of scripts used for bulk editing, see
<filename>convert_oid2name.pl</filename>
and <filename>remove_pg_type_oid_symbols.pl</filename> attached to this
message:
<ulink url="https://www.postgresql.org/message-id/CAJVSVGVX8gXnPm+Xa=DxR7kFYprcQ1tNcCT5D0O3ShfnM6jehA@mail.gmail.com"></ulink>
さらなる大量編集スクリプトの例については、https://www.postgresql.org/message-id/CAJVSVGVX8gXnPm+Xa=DxR7kFYprcQ1tNcCT5D0O3ShfnM6jehA@mail.gmail.comに付随するconvert_oid2name.plとremove_pg_type_oid_symbols.plを見てください。