Significant revisions to the XML-related specifications in ISO/IEC 9075-14 (SQL/XML) were introduced with SQL:2006. <productname>PostgreSQL</productname>'s implementation of the XML data type and related functions largely follows the earlier 2003 edition, with some borrowing from later editions. In particular: SQL:2006でISO/IEC 9075-14 (SQL/XML)のXML関連の仕様についての重要な改定が導入されました。 PostgreSQLのXMLデータ型と関連する関数の実装は、いくつか新しい版から取り入れつつ、主として2003以前の版に従っていました。 特に:
Where the current standard provides a family of XML data types
to hold <quote>document</quote> or <quote>content</quote> in
untyped or XML Schema-typed variants, and a type
<type>XML(SEQUENCE)</type> to hold arbitrary pieces of XML content,
<productname>PostgreSQL</productname> provides the single
<type>xml</type> type, which can hold <quote>document</quote> or
<quote>content</quote>. There is no equivalent of the
standard's <quote>sequence</quote> type.
現在の標準は、型付けされていないかXMLスキーマで型付けされている変数で「document」や「content」を格納するXMLのデータ型の一群や、任意のXML内容の断片を格納するXML(SEQUENCE)型を提供しますが、PostgreSQLは「document」か「content」だけを格納できる単一のxml型を提供します。
標準の「sequence」型と同等のものはありません。
<productname>PostgreSQL</productname> provides two functions introduced in SQL:2006, but in variants that use the XPath 1.0 language, rather than XML Query as specified for them in the standard. PostgreSQLはSQL:2006で導入された二つの関数を提供しますが、それらに対して標準で指定されているXML QueryではなくXPath 1.0言語を使う変形としてです。
This section presents some of the resulting differences you may encounter. 本章では遭遇するであろういくつかの結果の違いを示します。
The <productname>PostgreSQL</productname>-specific functions
<function>xpath()</function> and <function>xpath_exists()</function>
query XML documents using the XPath language.
<productname>PostgreSQL</productname> also provides XPath-only variants
of the standard functions <function>XMLEXISTS</function> and
<function>XMLTABLE</function>, which officially use
the XQuery language. For all of these functions,
<productname>PostgreSQL</productname> relies on the
<application>libxml2</application> library, which provides only XPath 1.0.
PostgreSQL固有の関数xpath()とxpath_exists()はXPath言語を使ってXML文書に問い合わせます。
PostgreSQLは、公式にはXQuery言語を使う標準関数のXMLEXISTSとXMLTABLEについても、XPathのみという変形を提供しています。
これら全ての関数についてPostgreSQLは、XPath 1.0のみを提供する、libxml2ライブラリに依存しています。
There is a strong connection between the XQuery language and XPath versions 2.0 and later: any expression that is syntactically valid and executes successfully in both produces the same result (with a minor exception for expressions containing numeric character references or predefined entity references, which XQuery replaces with the corresponding character while XPath leaves them alone). But there is no such connection between these languages and XPath 1.0; it was an earlier language and differs in many respects. XQuery言語とXPathバージョン2.0以降との間には強い関連があり、両方で構文として有効で正常に実行できる全ての式は同じ結果を生成します（数字を含む式の参照や事前定義された要素の参照について細かな例外があり、それらをXQueryは対応する文字で置換しますが、XPathはそのままにします）。 しかし、これら言語とXPath 1.0との間には、このような関連はありません。XPath 1.0はより古い言語であって多くの点で異なります。
There are two categories of limitation to keep in mind: the restriction from XQuery to XPath for the functions specified in the SQL standard, and the restriction of XPath to version 1.0 for both the standard and the <productname>PostgreSQL</productname>-specific functions. 認識すべき二つの種類の制限事項があります。 SQL標準で指定される関数に対してXQueryでなくXPathであるという制限と、標準関数でもPostgreSQL固有関数でもXPathがバージョン1.0であるという制限です。
Features of XQuery beyond those of XPath include: XPathに含まれないXQueryの機能:
XQuery expressions can construct and return new XML nodes, in addition to all possible XPath values. XPath can create and return values of the atomic types (numbers, strings, and so on) but can only return XML nodes that were already present in documents supplied as input to the expression. XQueryの式は、全てのXPathでできる値に加えて、新たなXMLノードを生成して返すことができます。 XPathは原子型（数値、文字列など）の値を作成して返すことができますが、XMLノードは入力として式に与えられる文書にあらかじめ存在するものしか返せません。
XQuery has control constructs for iteration, sorting, and grouping. XQueryは構造に対する反復、並べ替え、グループ化の制御ができます。
XQuery allows declaration and use of local functions. XQueryでは局所関数を宣言して使用することができます。
Recent XPath versions begin to offer capabilities overlapping with
these (such as functional-style <function>for-each</function> and
<function>sort</function>, anonymous functions, and
<function>parse-xml</function> to create a node from a string),
but such features were not available before XPath 3.0.
最近のXPathバージョンはこれらをカバーする機能（関数形式のfor-eachとsort、無名関数、文字列からノードを作るparse-xmlなど）を提供し始めていますが、これら機能はXPath 3.0より前では提供されません。
For developers familiar with XQuery and XPath 2.0 or later, XPath 1.0 presents a number of differences to contend with: XQueryとXPath 2.0以降に慣れた開発者にとって、XPath 1.0には以下の対処すべき違いがあります。
The fundamental type of an XQuery/XPath expression, the
<type>sequence</type>, which can contain XML nodes, atomic values,
or both, does not exist in XPath 1.0. A 1.0 expression can only
produce a node-set (containing zero or more XML nodes), or a single
atomic value.
XQuery/XPath式の基本的な型で、XMLノードや原子値、それらの両方を複数含むことができるsequenceがXPath 1.0には存在しません。
1.0の式はノードセット（0個以上のXMLノードを含む）か単独の原子値のみ生成できます。
Unlike an XQuery/XPath sequence, which can contain any desired items in any desired order, an XPath 1.0 node-set has no guaranteed order and, like any set, does not allow multiple appearances of the same item. 任意の要素群を任意の順序で含めることができるXQuery/XPathのシーケンスと違い、XPath 1.0のノードセットは順序保証がなく、集合のように、同じ要素が複数出現することを許しません。
The <application>libxml2</application> library does seem to always return node-sets to <productname>PostgreSQL</productname> with their members in the same relative order they had in the input document. Its documentation does not commit to this behavior, and an XPath 1.0 expression cannot control it. libxml2ライブラリは常に入力文書での順序に連動した同じ順序でPostgreSQLにノードセット返すように見えます。 ライブラリのドキュメントはこの振る舞いを保証していませんし、XPath 1.0式はこれを制御できません。
While XQuery/XPath provides all of the types defined in XML Schema
and many operators and functions over those types, XPath 1.0 has only
node-sets and the three atomic types <type>boolean</type>,
<type>double</type>, and <type>string</type>.
XQuery/XPathがXML Schemaで定義されたすべての型と、これらの型に対する多数の演算子や関数を提供する一方、XPath 1.0ではノードセットと3つの原子型boolean、double、stringのみが使えます。
XPath 1.0 has no conditional operator. An XQuery/XPath expression
such as <literal>if ( hat ) then hat/@size else "no hat"</literal>
has no XPath 1.0 equivalent.
XPath 1.0には条件演算子がありません。
if ( hat ) then hat/@size else "no hat"といったXQuery/XPathの式は、XPath 1.0では実現できません。
XPath 1.0 has no ordering comparison operator for strings. Both
<literal>"cat" < "dog"</literal> and
<literal>"cat" > "dog"</literal> are false, because each is a
numeric comparison of two <literal>NaN</literal>s. In contrast,
<literal>=</literal> and <literal>!=</literal> do compare the strings
as strings.
XPath 1.0には文字列の順序比較演算子がありません。
"cat" < "dog"も"cat" > "dog"も、どちらも2つのNaNの数値比較であるため、偽になります。
対照的に=と!=は文字列を文字列として比較します。
XPath 1.0 blurs the distinction between
<firstterm>value comparisons</firstterm> and
<firstterm>general comparisons</firstterm> as XQuery/XPath define
them. Both <literal>sale/@hatsize = 7</literal> and
<literal>sale/@customer = "alice"</literal> are existentially
quantified comparisons, true if there is
any <literal>sale</literal> with the given value for the
attribute, but <literal>sale/@taxable = false()</literal> is a
value comparison to the
<firstterm>effective boolean value</firstterm> of a whole node-set.
It is true only if no <literal>sale</literal> has
a <literal>taxable</literal> attribute at all.
XPath 1.0では、XQuery/XPathで定義されているところの値比較と一般比較の区別が曖昧です。
sale/@hatsize = 7とsale/@customer = "alice"は、共に実体のある定量的な比較であり、与えられた属性に対する値を伴うsaleがあるなら真ですが、sale/@taxable = false()はノードセット全体の有効なブール値との値比較です。
taxable属性を持つsaleが全く無い場合のみ真になります。
In the XQuery/XPath data model, a <firstterm>document
node</firstterm> can have either document form (i.e., exactly one
top-level element, with only comments and processing instructions
outside of it) or content form (with those constraints
relaxed). Its equivalent in XPath 1.0, the
<firstterm>root node</firstterm>, can only be in document form.
This is part of the reason an <type>xml</type> value passed as the
context item to any <productname>PostgreSQL</productname>
XPath-based function must be in document form.
XQuery/XPathデータモデルでは、ドキュメントノードはドキュメント形式（すなわちコメントと外側の処理指示だけを伴う厳密に一つだけのトップレベル要素）かコンテキスト形式（これらの制約が緩められたもの）のいずれかを持つことができます。
これに対してXPath 1.0ではルートノードはドキュメント形式のみです。
このことは、PostgreSQLのXPathに基づくどの関数に対してもコンテキスト要素として渡されるxml値がドキュメント形式でなければならない理由の一つです。
The differences highlighted here are not all of them. In XQuery and the 2.0 and later versions of XPath, there is an XPath 1.0 compatibility mode, and the W3C lists of <ulink url='https://www.w3.org/TR/2010/REC-xpath-functions-20101214/#xpath1-compatibility'>function library changes</ulink> and <ulink url='https://www.w3.org/TR/xpath20/#id-backwards-compatibility'>language changes</ulink> applied in that mode offer a more complete (but still not exhaustive) account of the differences. The compatibility mode cannot make the later languages exactly equivalent to XPath 1.0. ここに挙げたものは違いの全てではありません。 XQueryと2.0以降のXPathには、XPath 1.0互換モードがあり、このモードで摘要されるW3Cの関数ライブラリの変更点と言語の変更点のリストは、より完成された（しかし未だ完全ではない）違いの説明を提供します。 この互換モードは新しい言語を正確にXPath 1.0と等しくできるわけではありません。
In SQL:2006 and later, both directions of conversion between standard SQL data types and the XML Schema types are specified precisely. However, the rules are expressed using the types and semantics of XQuery/XPath, and have no direct application to the different data model of XPath 1.0. SQL:2006以降では、標準SQLデータ型とXMLスキーマ型の間の両方向の変換が正確に明記されています。 しかしながら、その規則はXQuery/XPathの型と意味を用いて説明されていて、XPath1.0の異なるデータモデルへの直接の適用は含まれません。
When <productname>PostgreSQL</productname> maps SQL data values to XML
(as in <function>xmlelement</function>), or XML to SQL (as in the output
columns of <function>xmltable</function>), except for a few cases
treated specially, <productname>PostgreSQL</productname> simply assumes
that the XML data type's XPath 1.0 string form will be valid as the
text-input form of the SQL datatype, and conversely. This rule has the
virtue of simplicity while producing, for many data types, results similar
to the mappings specified in the standard.
PostgreSQLがSQLデータの値からXML（xmlelementで）、あるいは、XMLからSQL（xmltableの出力列で）に変換するとき、特別扱いされる一部の場合を除いて、PostgreSQLは単純にXMLデータ型のXPath 1.0文字列形式がSQLデータ型のテキスト入力形式として有効であると想定し、逆向きの変換でも同様です。
この規則は多くのデータ型に対して実装が単純という長所を持ち、標準で明記された変換と似た結果になります。
Where interoperability with other systems is a concern, for some data types, it may be necessary to use data type formatting functions (such as those in <xref linkend="functions-formatting"/>) explicitly to produce the standard mappings. 他システムとの相互運用性が重要なところでは、一部のデータ型に対して標準の変換を実現するために明示的に（9.8にあるような）データ型整形関数を使うことがおそらく必要です。
This section concerns limits that are not inherent in the <application>libxml2</application> library, but apply to the current implementation in <productname>PostgreSQL</productname>. 本節はlibxml2ライブラリ固有の制限ではないけれども、PostgreSQLの現在の実装で適用される制限について述べます。
BY VALUEのみ対応 #
The SQL standard defines two <firstterm>passing mechanisms</firstterm>
that apply when passing an XML argument from SQL to an XML function or
receiving a result: <literal>BY REF</literal>, in which a particular XML
value retains its node identity, and <literal>BY VALUE</literal>, in which
the content of the XML is passed but node identity is not preserved. A
mechanism can be specified before a list of parameters, as the default
mechanism for all of them, or after any parameter, to override the
default.
SQL標準は、SQLからXML関数にXML引数を渡す、あるいは結果を受け取るときに適用される2つの引き渡し方式を定義しています。
BY REFでは特定のXML値がそのノードIDを保持し、BY VALUEではXML内容が渡されてノードIDは保持されません。
方式は、パラメータリストの手前にそれらすべてのデフォルトとして、あるいは、各パラメータの後ろにデフォルトを上書きするものとして、指定することができます。
To illustrate the difference, if
<replaceable>x</replaceable> is an XML value, these two queries in
an SQL:2006 environment would produce true and false, respectively:
違いを例を挙げて示します。もしxがXML値であるなら、SQL:2006環境でのこれら2つの問合わせは、それぞれtrueとfalseを返すでしょう。
SELECT XMLQUERY('$a is $b' PASSING BY REF x AS a, x AS b NULL ON EMPTY);
SELECT XMLQUERY('$a is $b' PASSING BY VALUE x AS a, x AS b NULL ON EMPTY);
<productname>PostgreSQL</productname> will accept
<literal>BY VALUE</literal> or <literal>BY REF</literal> in an
<function>XMLEXISTS</function> or <function>XMLTABLE</function>
construct, but it ignores them. The <type>xml</type> data type holds
a character-string serialized representation, so there is no node
identity to preserve, and passing is always effectively <literal>BY
VALUE</literal>.
PostgreSQLは、XMLEXISTSやXMLTABLE構築でBY VALUEやBY REFを受け付けますが、無視します。
xmlデータ型は連続した文字列表現を持ちますので、保持されるノードIDは無く、引き渡しは実際には常にBY VALUEです。
The XPath-based functions support passing one parameter to serve as the XPath expression's context item, but do not support passing additional values to be available to the expression as named parameters. XPathベースの関数はXPath式のコンテキスト要素として働くようにパラメータを渡すことをサポートしていますが、名前付きパラメータの式にできるように追加値を渡すことはサポートしていません。
XML(SEQUENCE)型は無い #
The <productname>PostgreSQL</productname> <type>xml</type> data type
can only hold a value in <literal>DOCUMENT</literal>
or <literal>CONTENT</literal> form. An XQuery/XPath expression
context item must be a single XML node or atomic value, but XPath 1.0
further restricts it to be only an XML node, and has no node type
allowing <literal>CONTENT</literal>. The upshot is that a
well-formed <literal>DOCUMENT</literal> is the only form of XML value
that <productname>PostgreSQL</productname> can supply as an XPath
context item.
PostgreSQLのxmlデータ型はDOCUMENTまたはCONTENT形式でのみ値を保持できます。
XQuery/XPath式コンテキストの要素は単独のXMLノードか原子値でなければなりません。しかし、XPath 1.0ではさらにXMLノードのみに制限していて、加えてCONTENTが可能なノードタイプを持ちません。
結果として、整形式のDOCUMENTのみが、PostgreSQLでXPathコンテキストの要素として提供されるXML値の形式です。