Here are two simple examples of defining composite types: 複合型の宣言の例を以下に2つ示します。

CREATE TYPE complex AS (
    r       double precision,
    i       double precision
);

CREATE TYPE inventory_item AS (
    name            text,
    supplier_id     integer,
    price           numeric
);

The syntax is comparable to <command>CREATE TABLE</command>, except that only field names and types can be specified; no constraints (such as <literal>NOT NULL</literal>) can presently be included. Note that the <literal>AS</literal> keyword is essential; without it, the system will think a different kind of <command>CREATE TYPE</command> command is meant, and you will get odd syntax errors. この構文は、フィールド名とその型のみを指定できるという点を除き、CREATE TABLEと同等です。 現在は、制約（NOT NULLなど）を含めることはできません。 ASキーワードが重要であることに注意してください。 これがないと、システムはCREATE TYPEの意味を異なって解釈し、おかしな構文エラーを引き起こします。

Having defined the types, we can use them to create tables: 定義済みの型を使用して、以下のようにテーブルや関数を生成することができます。

CREATE TABLE on_hand (
    item      inventory_item,
    count     integer
);

INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);

or functions: また、関数においては以下のように利用できます。

CREATE FUNCTION price_extension(inventory_item, integer) RETURNS numeric
AS 'SELECT $1.price * $2' LANGUAGE SQL;

SELECT price_extension(item, 10) FROM on_hand;

Whenever you create a table, a composite type is also automatically created, with the same name as the table, to represent the table's row type. For example, had we said: テーブルを生成する時には、テーブルの行型を表現するために、テーブル名と同じ名前の複合型も自動的に生成されます。 例えば、以下のように

CREATE TABLE inventory_item (
    name            text,
    supplier_id     integer REFERENCES suppliers,
    price           numeric CHECK (price > 0)
);

then the same <literal>inventory_item</literal> composite type shown above would come into being as a byproduct, and could be used just as above. Note however an important restriction of the current implementation: since no constraints are associated with a composite type, the constraints shown in the table definition <emphasis>do not apply</emphasis> to values of the composite type outside the table. (To work around this, create a <glossterm linkend="glossary-domain">domain</glossterm> over the composite type, and apply the desired constraints as <literal>CHECK</literal> constraints of the domain.) テーブルを作成すると、上述のものと同じinventory_itemという複合型が副次的に作成され、同様に使用することができるようになります。 しかし、現在の実装には、次のような重要な制限があることに注意してください。 複合型には制約が関連付けられませんので、テーブル定義に含まれる制約は、テーブルの外部に作成される複合型には適用されません。 （これを回避するためには、複合型を含むドメインを作成し、ドメインのCHECK制約として望みの制約を適用します。）

To write a composite value as a literal constant, enclose the field values within parentheses and separate them by commas. You can put double quotes around any field value, and must do so if it contains commas or parentheses. (More details appear <link linkend="rowtypes-io-syntax">below</link>.) Thus, the general format of a composite constant is the following: 複合型をリテラル定数として記述するには、フィールド値をカンマで区切り、それらを括弧で括ります。 フィールド値を二重引用符で括ることができ、また、値にカンマや括弧を含む場合は二重引用符で括らなければなりません （より詳細については後で説明します）。 したがって、複合型の定数の一般的な書式は以下のようになります。

'( val1 , val2 , ... )'

An example is: 以下に例を示します。

'("fuzzy dice",42,1.99)'

which would be a valid value of the <literal>inventory_item</literal> type defined above. To make a field be NULL, write no characters at all in its position in the list. For example, this constant specifies a NULL third field: これは、上述のinventory_item型の値として有効なものです。 フィールドをNULLにするには、リスト中の該当位置を空にします。 例えば、以下の定数は3番目のフィールドにNULLを指定しています。

'("fuzzy dice",42,)'

If you want an empty string rather than NULL, write double quotes: NULLではなく空文字列にしたいのであれば、以下のように引用符を二重に記述します。

'("",42,)'

Here the first field is a non-NULL empty string, the third is NULL. これにより、最初のフィールドは非NULLの空文字列に、3番目のフィールドはNULLになります。

(These constants are actually only a special case of the generic type constants discussed in <xref linkend="sql-syntax-constants-generic"/>. The constant is initially treated as a string and passed to the composite-type input conversion routine. An explicit type specification might be necessary to tell which type to convert the constant to.) （実際には、こうした定数は4.1.2.7で説明した、一般的な型の定数の特殊な場合に過ぎません。 定数はまず、文字列として扱われ、複合型の入力変換処理に渡されます。 定数をどの型に変換するかを示すため、明示的な型指定が必要になることもあります。）

The <literal>ROW</literal> expression syntax can also be used to construct composite values. In most cases this is considerably simpler to use than the string-literal syntax since you don't have to worry about multiple layers of quoting. We already used this method above: また、ROW式構文も、複合値を生成する際に使用することができます。 複数の階層に渡る引用符について考慮する必要がないため、おそらくほとんどの場合、これは文字列リテラル構文よりも簡単に使用できます。 上記において、既にこの方法を使用しています。

ROW('fuzzy dice', 42, 1.99)
ROW('', 42, NULL)

The ROW keyword is actually optional as long as you have more than one field in the expression, so these can be simplified to: 式の中に2つ以上のフィールドがある場合には、ROWキーワードは実際には省略することができます。 ですので、以下のように簡略化することができます。

('fuzzy dice', 42, 1.99)
('', 42, NULL)

The <literal>ROW</literal> expression syntax is discussed in more detail in <xref linkend="sql-syntax-row-constructors"/>. ROW構文については4.2.13でより詳細に説明します。

To access a field of a composite column, one writes a dot and the field name, much like selecting a field from a table name. In fact, it's so much like selecting from a table name that you often have to use parentheses to keep from confusing the parser. For example, you might try to select some subfields from our <literal>on_hand</literal> example table with something like: 複合型の列のフィールドにアクセスするには、テーブル名からフィールドを選択する場合とほぼ同様に、ドットとフィールド名を記述します。 実際、テーブル名からの選択とかなり似ていますので、パーサを混乱させないように括弧を使用しなければならないことがしばしばあります。 例えば、on_handというテーブルの例からサブフィールドを選択しようとした場合、以下のように書くかもしれません。

SELECT item.name FROM on_hand WHERE item.price > 9.99;

This will not work since the name <literal>item</literal> is taken to be a table name, not a column name of <literal>on_hand</literal>, per SQL syntax rules. You must write it like this: これは、SQLの構文規則に従ってitemがon_handの列名ではなくテーブル名として解釈されるため、動作しません。 以下のように記述しなければなりません。

SELECT (item).name FROM on_hand WHERE (item).price > 9.99;

or if you need to use the table name as well (for instance in a multitable query), like this: また、テーブル名も使用しなければならない場合（例えば複数テーブルに対する問い合わせ）、以下のようになります。

SELECT (on_hand.item).name FROM on_hand WHERE (on_hand.item).price > 9.99;

Now the parenthesized object is correctly interpreted as a reference to the <literal>item</literal> column, and then the subfield can be selected from it. これで、括弧で括られたオブジェクトは正しくitem列への参照として解釈され、サブフィールドはそこから選択できるようになります。

Similar syntactic issues apply whenever you select a field from a composite value. For instance, to select just one field from the result of a function that returns a composite value, you'd need to write something like: 似たような構文上の問題は、複合型からフィールドを選択する時、常に発生します。 例えば、複合型の値を返す関数の結果から1つだけフィールドを選択する場合、以下のように記述しなければなりません。

SELECT (my_func(...)).field FROM ...

Without the extra parentheses, this will generate a syntax error. 追加の括弧がないと、これは構文エラーを生成します。

The special field name <literal>*</literal> means <quote>all fields</quote>, as further explained in <xref linkend="rowtypes-usage"/>. 8.16.5でより詳細に説明する通り、*という特別なフィールド名は「すべてのフィールド」を意味します。

Here are some examples of the proper syntax for inserting and updating composite columns. First, inserting or updating a whole column: 複合型の列への挿入と更新についての適切な構文の例をいくつか示します。 まず、列全体を挿入、更新する例です。

INSERT INTO mytab (complex_col) VALUES((1.1,2.2));

UPDATE mytab SET complex_col = ROW(1.1,2.2) WHERE ...;

The first example omits <literal>ROW</literal>, the second uses it; we could have done it either way. 最初の例ではROWを省略し、2番目の例ではROWを使用しています。 どちらの方法でも行うことができます。

We can update an individual subfield of a composite column: 以下のようにして、複合型の列の個々のサブフィールドを更新することができます。

UPDATE mytab SET complex_col.r = (complex_col).r + 1 WHERE ...;

Notice here that we don't need to (and indeed cannot) put parentheses around the column name appearing just after <literal>SET</literal>, but we do need parentheses when referencing the same column in the expression to the right of the equal sign. ここで、SET直後の列名の周りに括弧を記述する必要がないこと（実際には記述できないこと）、しかし、等号の右で同じ列を参照する場合には括弧が必要なことに注意してください。

And we can specify subfields as targets for <command>INSERT</command>, too: また、INSERTの対象としてサブフィールドを指定することもできます。

INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);

Had we not supplied values for all the subfields of the column, the remaining subfields would have been filled with null values. 列のサブフィールド全ての値を与えていなければ、残りのサブフィールドはNULL値になります。

There are various special syntax rules and behaviors associated with composite types in queries. These rules provide useful shortcuts, but can be confusing if you don't know the logic behind them. 問い合わせ内での複合型に関連して様々な特別な構文規則や動作があります。 これらの規則により便利なショートカットが提供されますが、その背後にある論理を知らないと混乱を招くかもしれません。

In <productname>PostgreSQL</productname>, a reference to a table name (or alias) in a query is effectively a reference to the composite value of the table's current row. For example, if we had a table <structname>inventory_item</structname> as shown <link linkend="rowtypes-declaring">above</link>, we could write: PostgreSQLでは、問い合わせでのテーブル名（または別名）の参照は、実質的にはテーブルの現在行の複合型の値への参照と同じになります。 例えば、前に示したinventory_itemというテーブルがあるとして、次のように記述することができます。

SELECT c FROM inventory_item c;

This query produces a single composite-valued column, so we might get output like: この問い合わせは単一の複合型の値の列を生成するので、出力は以下のようになります。

           c
------------------------
 ("fuzzy dice",42,1.99)
(1 row)

Note however that simple names are matched to column names before table names, so this example works only because there is no column named <structfield>c</structfield> in the query's tables. ただし、単純な名前はテーブル名より先に列名に対してマッチさせられるので、この例は問い合わせのテーブルにcという名前の列がないから動作したに過ぎないことに注意してください。

The ordinary qualified-column-name syntax <replaceable>table_name</replaceable><literal>.</literal><replaceable>column_name</replaceable> can be understood as applying <link linkend="field-selection">field selection</link> to the composite value of the table's current row. (For efficiency reasons, it's not actually implemented that way.) 通常のtable_name.column_nameという列名修飾の構文は、フィールド選択をテーブルの現在行の複合型の値に対して適用していると考えることもできます。 （効率の問題から、実際にはそのような実装にはなっていません。）

When we write

SELECT c.* FROM inventory_item c;

then, according to the SQL standard, we should get the contents of the table expanded into separate columns: 上記のSQLについて、標準SQLではテーブルの内容が別々の列に展開されて、次のような結果になることを定めています。

    name    | supplier_id | price
------------+-------------+-------
 fuzzy dice |          42 |  1.99
(1 row)

as if the query were つまりこれは、問い合わせが以下であったかのように動作するということです。

SELECT c.name, c.supplier_id, c.price FROM inventory_item c;

<productname>PostgreSQL</productname> will apply this expansion behavior to any composite-valued expression, although as shown <link linkend="rowtypes-accessing">above</link>, you need to write parentheses around the value that <literal>.*</literal> is applied to whenever it's not a simple table name. For example, if <function>myfunc()</function> is a function returning a composite type with columns <structfield>a</structfield>, <structfield>b</structfield>, and <structfield>c</structfield>, then these two queries have the same result: PostgreSQLでは、この展開の動作をすべての複合型の値の式に適用します。 ただし、前に説明したように、.*をつける値が単純なテーブル名でないときは、必ずそれを括弧で括る必要があります。 例えば、myfunc()が列a、b、cからなる複合型を返す関数だとすると、次の２つの問い合わせは同じ結果を返します。

SELECT (myfunc(x)).* FROM some_table;
SELECT (myfunc(x)).a, (myfunc(x)).b, (myfunc(x)).c FROM some_table;

SELECT m.* FROM some_table, LATERAL myfunc(x) AS m;

The <replaceable>composite_value</replaceable><literal>.*</literal> syntax results in column expansion of this kind when it appears at the top level of a <link linkend="queries-select-lists"><command>SELECT</command> output list</link>, a <link linkend="dml-returning"><literal>RETURNING</literal> list</link> in <command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>/<command>MERGE</command>, a <link linkend="queries-values"><literal>VALUES</literal> clause</link>, or a <link linkend="sql-syntax-row-constructors">row constructor</link>. In all other contexts (including when nested inside one of those constructs), attaching <literal>.*</literal> to a composite value does not change the value, since it means <quote>all columns</quote> and so the same composite value is produced again. For example, if <function>somefunc()</function> accepts a composite-valued argument, these queries are the same: composite_value.*の構文は、それがSELECTの出力リスト、INSERT/UPDATE/DELETE/MERGEのRETURNINGリスト、VALUES句あるいは行コンストラクタの最上位に記述された場合、この種の列展開がされます。 それ以外の場合（これらの構文の内側に入れ子になっている場合を含みます）は、複合型の値に.*を付加しても、値は変わりません。 なぜなら、それは「すべての列」を意味するため、同じ複合型の値が繰り返し生成されるからです。 例えば、somefunc()が複合型の値の引数をとるとして、以下の問い合わせは同じです。

SELECT somefunc(c.*) FROM inventory_item c;
SELECT somefunc(c) FROM inventory_item c;

In both cases, the current row of <structname>inventory_item</structname> is passed to the function as a single composite-valued argument. Even though <literal>.*</literal> does nothing in such cases, using it is good style, since it makes clear that a composite value is intended. In particular, the parser will consider <literal>c</literal> in <literal>c.*</literal> to refer to a table name or alias, not to a column name, so that there is no ambiguity; whereas without <literal>.*</literal>, it is not clear whether <literal>c</literal> means a table name or a column name, and in fact the column-name interpretation will be preferred if there is a column named <literal>c</literal>. どちらの場合もinventory_itemの現在行が単一の複合型の値の引数として関数に渡されます。 このような場合に.*は何もしませんが、それをつけることにより、複合型の値であることを意図しているのが明確になるので、つけるのは良い習慣です。 特に、パーサがc.*のcを列名ではなくテーブル名あるいは別名を参照するものとみなす一方、.*がないとcがテーブル名なのか列名なのか明らかではなく、実際には、cという名前の列があれば列名としての解釈が優先されてしまいます。

Another example demonstrating these concepts is that all these queries mean the same thing: これらの考え方を示す別の例をあげると、以下の３つの問い合わせは同じ意味になります。

SELECT * FROM inventory_item c ORDER BY c;
SELECT * FROM inventory_item c ORDER BY c.*;
SELECT * FROM inventory_item c ORDER BY ROW(c.*);

All of these <literal>ORDER BY</literal> clauses specify the row's composite value, resulting in sorting the rows according to the rules described in <xref linkend="composite-type-comparison"/>. However, if <structname>inventory_item</structname> contained a column named <structfield>c</structfield>, the first case would be different from the others, as it would mean to sort by that column only. Given the column names previously shown, these queries are also equivalent to those above: これらのORDER BY句はすべて行の複合型の値を指定しており、9.25.6で説明される規則に従って行を並べ替えた結果になります。 ただし、inventory_itemにcという名前の列がある場合は、最初の例はその列によってのみ並べ替えられるので、他の２つとは異なるものになります。 以前に示したのと同じ列名であるとしたら、以下の問い合わせも上記のものと同じになります。

SELECT * FROM inventory_item c ORDER BY ROW(c.name, c.supplier_id, c.price);
SELECT * FROM inventory_item c ORDER BY (c.name, c.supplier_id, c.price);

(The last case uses a row constructor with the key word <literal>ROW</literal> omitted.) （最後の例はキーワードROWを省略した行コンストラクタを使用しています。）

Another special syntactical behavior associated with composite values is that we can use <firstterm>functional notation</firstterm> for extracting a field of a composite value. The simple way to explain this is that the notations <literal><replaceable>field</replaceable>(<replaceable>table</replaceable>)</literal> and <literal><replaceable>table</replaceable>.<replaceable>field</replaceable></literal> are interchangeable. For example, these queries are equivalent: 複合型の値に関連したもう一つの特別な構文的動作は、複合型の値のフィールドを取り出す時に関数的記法を使用できることです。 これを簡単に説明するなら、field(table)という記法とtable.fieldという記法は相互に交換可能です。 例えば、以下の問い合わせは同等です。

SELECT c.name FROM inventory_item c WHERE c.price > 1000;
SELECT name(c) FROM inventory_item c WHERE price(c) > 1000;

Moreover, if we have a function that accepts a single argument of a composite type, we can call it with either notation. These queries are all equivalent: さらに、複合型の引数を１つだけとる関数があるとして、それをどちらの記法でも呼び出すことができます。 以下の問い合わせはすべて同等です。

SELECT somefunc(c) FROM inventory_item c;
SELECT somefunc(c.*) FROM inventory_item c;
SELECT c.somefunc FROM inventory_item c;

This equivalence between functional notation and field notation makes it possible to use functions on composite types to implement <quote>computed fields</quote>. この関数的記法とフィールド記法の同等性により、複合型に対する関数を使用して「計算されたフィールド」を実装することができます。 An application using the last query above wouldn't need to be directly aware that <literal>somefunc</literal> isn't a real column of the table. 上の最後の問い合わせを使用するアプリケーションは、somefuncがテーブルの真の列ではないことを直接には意識する必要がありません。

The external text representation of a composite value consists of items that are interpreted according to the I/O conversion rules for the individual field types, plus decoration that indicates the composite structure. The decoration consists of parentheses (<literal>(</literal> and <literal>)</literal>) around the whole value, plus commas (<literal>,</literal>) between adjacent items. Whitespace outside the parentheses is ignored, but within the parentheses it is considered part of the field value, and might or might not be significant depending on the input conversion rules for the field data type. For example, in: 複合型の外部テキスト表現は、個々のフィールド用のI/O変換規則に従って解釈される項目群と、複合構造を意味する修飾から構成されます。 この修飾は、値全体を括る括弧（(および)）と隣接した項目間のカンマ（,）で構成されます。 括弧の外側の空白文字は無視されますが、括弧の内部ではフィールド値の一部とみなされます。 ただし、空白に意味があるかないかについては、そのフィールドのデータ型用の入力変換規則に従います。 例えば、

'(  42)'

the whitespace will be ignored if the field type is integer, but not if it is text. 括弧内の空白文字は、そのフィールド型が整数の場合は無視されますが、テキストの場合は無視されません。

As shown previously, when writing a composite value you can write double quotes around any individual field value. You <emphasis>must</emphasis> do so if the field value would otherwise confuse the composite-value parser. In particular, fields containing parentheses, commas, double quotes, or backslashes must be double-quoted. To put a double quote or backslash in a quoted composite field value, precede it with a backslash. (Also, a pair of double quotes within a double-quoted field value is taken to represent a double quote character, analogously to the rules for single quotes in SQL literal strings.) Alternatively, you can avoid quoting and use backslash-escaping to protect all data characters that would otherwise be taken as composite syntax. 前述の通り、複合型の値を記述する時には、個々のフィールド値を二重引用符で括ることができます。 もし、フィールド値が複合型値用のパーサを混乱させる場合には、これは必須です。 具体的には、括弧、カンマ、二重引用符、バックスラッシュを含むフィールドの場合、二重引用符で括る必要があります。 引用符で括った複合型のフィールド値内に二重引用符やバックスラッシュが存在する場合、その前にバックスラッシュを付けてください （また、引用符で括った複合型のフィールド値内に二重の引用符の組み合わせがあると、これは二重引用符を表す文字として解釈されます。 これは、SQLリテラル文字列内の単一引用符の規則と同じです）。 そのままでは複合型に対する構文として解釈されてしまう、全てのデータ文字を保護する他の方法として、引用符付けをせずにバックスラッシュによるエスケープを使用することができます。

A completely empty field value (no characters at all between the commas or parentheses) represents a NULL. To write a value that is an empty string rather than NULL, write <literal>""</literal>. 完全な空フィールド値（カンマや括弧の間にまったく文字がないもの）はNULLを表します。 NULLではなく空文字列を値として記述するには "" と記述してください。

The composite output routine will put double quotes around field values if they are empty strings or contain parentheses, commas, double quotes, backslashes, or white space. (Doing so for white space is not essential, but aids legibility.) Double quotes and backslashes embedded in field values will be doubled. 複合型の出力処理では、もしフィールド値が空文字列の場合や括弧、カンマ、二重引用符、バックスラッシュ、空白文字を含む場合には、そのフィールド値を二重引用符で括って出力します （空白文字に対するこの処理は重要ではありませんが、可読性を高めます）。 フィールド値内に埋め込まれた二重引用符やバックスラッシュは二重化されます。

INSERT ... VALUES ('("\"\\")');