ISO/IEC 9075-14 (SQL/XML) 中与 XML 相关的规范在 SQL:2006 中引入了重大修订。PostgreSQL 对 XML 数据类型和相关函数的实现主要遵循较早的 2003 版本，并借鉴了后期版本的一些内容。特别是
当前标准提供了一系列 XML 数据类型来保存非类型化或 XML Schema 类型变体中的“document”或“content”，以及一个类型 XML(SEQUENCE) 来保存任意 XML 内容片段，PostgreSQL 提供了单一的 xml 类型，它可以保存“document”或“content”。没有标准中“sequence”类型的等效项。
PostgreSQL 提供了 SQL:2006 中引入的两个函数，但其变体使用 XPath 1.0 语言，而不是标准中为其指定的 XML Query。
PostgreSQL 不支持 RETURNING CONTENT 或 RETURNING SEQUENCE 子句，规范中定义为具有这些子句的函数隐式返回内容。
本节介绍您可能遇到的一些由此产生的差异。
PostgreSQL 特定的函数 xpath() 和 xpath_exists() 使用 XPath 语言查询 XML 文档。PostgreSQL 还提供了标准函数 XMLEXISTS 和 XMLTABLE 的仅 XPath 变体，这些函数正式使用 XQuery 语言。对于所有这些函数，PostgreSQL 依赖于 libxml2 库，该库仅提供 XPath 1.0。
XQuery 语言和 XPath 2.0 及更高版本之间存在很强的联系：任何在语法上有效并在两者中成功执行的表达式都会产生相同的结果（对于包含数字字符引用或预定义实体引用的表达式有一个小的例外，XQuery 将其替换为相应的字符，而 XPath 则保持不变）。但是，这些语言和 XPath 1.0 之间没有这种联系；它是一种较早的语言，在许多方面都有所不同。
需要记住两类限制：对于 SQL 标准中指定的函数，从 XQuery 到 XPath 的限制，以及对于标准和 PostgreSQL 特定函数，XPath 限制为 1.0 版本。
XPath 之外的 XQuery 的功能包括
除了所有可能的 XPath 值之外，XQuery 表达式还可以构造并返回新的 XML 节点。XPath 可以创建并返回原子类型的值（数字、字符串等），但只能返回 XML 节点，这些节点已经存在于作为表达式输入提供的文档中。
XQuery 具有用于迭代、排序和分组的控制结构。
XQuery 允许声明和使用局部函数。
最近的 XPath 版本开始提供与这些功能重叠的功能（例如函数式 for-each 和 sort、匿名函数和 parse-xml 从字符串创建节点），但在 XPath 3.0 之前，此类功能不可用。
对于熟悉 XQuery 和 XPath 2.0 或更高版本的开发人员，XPath 1.0 呈现出许多需要解决的差异
XQuery/XPath 表达式的基本类型 sequence（可以包含 XML 节点、原子值或两者）在 XPath 1.0 中不存在。1.0 表达式只能生成节点集（包含零个或多个 XML 节点）或单个原子值。
与可以以任意所需顺序包含任意所需项的 XQuery/XPath 序列不同，XPath 1.0 节点集没有保证的顺序，并且像任何集合一样，不允许同一项多次出现。
libxml2 库似乎总是以其成员在输入文档中出现的相同相对顺序将节点集返回给 PostgreSQL。其文档没有保证此行为，并且 XPath 1.0 表达式无法控制它。
虽然 XQuery/XPath 提供了 XML Schema 中定义的所有类型以及许多针对这些类型的运算符和函数，但 XPath 1.0 只有节点集和三种原子类型 boolean、double 和 string。
XPath 1.0 没有条件运算符。诸如 if ( hat ) then hat/@size else "no hat" 之类的 XQuery/XPath 表达式没有 XPath 1.0 等效项。
XPath 1.0 没有用于字符串的排序比较运算符。 "cat" < "dog" 和 "cat" > "dog" 均为假，因为每一个都是两个 NaN 的数值比较。相反，= 和 != 将字符串作为字符串进行比较。
XPath 1.0 模糊了 XQuery/XPath 定义的值比较和一般比较之间的区别。 sale/@hatsize = 7 和 sale/@customer = "alice" 都是存在量化的比较，如果存在任何具有给定属性值的 sale，则为真，但是 sale/@taxable = false() 是与整个节点集的有效布尔值进行的值比较。仅当没有任何 sale 具有 taxable 属性时，它才为真。
在 XQuery/XPath 数据模型中，文档节点可以具有文档形式（即，只有一个顶级元素，并且只有注释和处理指令位于其外部）或内容形式（放宽了这些约束）。它在 XPath 1.0 中的等效项，即根节点，只能采用文档形式。这是将 xml 值作为上下文项传递给任何 PostgreSQL 基于 XPath 的函数时，必须采用文档形式的部分原因。
这里强调的差异并非全部。在 XQuery 和 2.0 及更高版本的 XPath 中，存在 XPath 1.0 兼容模式，W3C 函数库更改和 语言更改列表中，在该模式下应用的更改提供了更完整（但仍然不详尽）的差异说明。兼容模式不能使后来的语言与 XPath 1.0 完全等效。
在 SQL:2006 及更高版本中，标准 SQL 数据类型和 XML Schema 类型之间的双向转换都得到了精确指定。但是，规则是使用 XQuery/XPath 的类型和语义表示的，并且不直接适用于 XPath 1.0 的不同数据模型。
当 PostgreSQL 将 SQL 数据值映射到 XML（如在 xmlelement 中）或将 XML 映射到 SQL（如在 xmltable 的输出列中）时，除了一些特殊处理的情况外，PostgreSQL 只是假设 XML 数据类型的 XPath 1.0 字符串形式将作为 SQL 数据类型的文本输入形式有效，反之亦然。此规则的优点是简单，同时对于许多数据类型，产生的结果类似于标准中指定的映射。
在需要与其他系统进行互操作的情况下，对于某些数据类型，可能需要显式使用数据类型格式化函数（如 第 9.8 节 中的函数）来生成标准映射。
本节涉及的限制并非 libxml2 库固有的限制，而是适用于 PostgreSQL 中的当前实现。
BY VALUE 传递机制 #SQL 标准定义了两种传递机制，当将 XML 参数从 SQL 传递到 XML 函数或接收结果时应用这两种传递机制：BY REF，其中特定的 XML 值保留其节点标识，以及 BY VALUE，其中传递 XML 的内容但不保留节点标识。可以在参数列表之前指定机制，作为所有参数的默认机制，或者在任何参数之后指定，以覆盖默认值。
为了说明差异，如果 x 是 XML 值，则在 SQL:2006 环境中，这两个查询将分别生成 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);
PostgreSQL 将接受 BY VALUE 或 BY REF 在 XMLEXISTS 或 XMLTABLE 构造中，但会忽略它们。 xml 数据类型保存字符序列化的表示形式，因此没有需要保留的节点标识，传递始终有效地等同于 BY VALUE。
基于 XPath 的函数支持传递一个参数作为 XPath 表达式的上下文项，但不支持传递其他值，以供表达式作为命名参数使用。
XML(SEQUENCE) 类型 #PostgreSQL 的 xml 数据类型只能以 DOCUMENT 或 CONTENT 形式保存值。XQuery/XPath 表达式上下文项必须是单个 XML 节点或原子值，但 XPath 1.0 进一步限制它只能是 XML 节点，并且没有允许 CONTENT 的节点类型。结果是，格式良好的 DOCUMENT 是 PostgreSQL 可以作为 XPath 上下文项提供的唯一形式的 XML 值。
如果您在文档中发现任何不正确、与您使用特定功能的经验不符或需要进一步澄清的地方，请使用此表单报告文档问题。