Skip to content

Commit e14b760

Browse files
ChenHuajunChenHuajun
committed
合并pr 283(features.sgml,func.sgml,monitoring.sgml)
1 parent 172029d commit e14b760

File tree

3 files changed

+2460
-251
lines changed

3 files changed

+2460
-251
lines changed

‎postgresql/doc/src/sgml/features.sgml

Lines changed: 211 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -23,8 +23,8 @@ ____________________________________________________________________________-->
2323
<para>
2424
The formal name of the SQL standard is ISO/IEC 9075 <quote>Database
2525
Language SQL</quote>. A revised version of the standard is released
26-
from time to time; the most recent update appearing in 2011.
27-
The 2011 version is referred to as ISO/IEC 9075:2011, or simply as SQL:2011.
26+
from time to time; the most recent update appearing in 2016.
27+
The 2016 version is referred to as ISO/IEC 9075:2016, or simply as SQL:2016.
2828
The versions prior to that were SQL:2008, SQL:2003, SQL:1999, and SQL-92. Each version
2929
replaces the previous one, so claims of conformance to earlier
3030
versions have no official merit.
@@ -38,7 +38,7 @@ ____________________________________________________________________________-->
3838
</para>
3939
____________________________________________________________________________-->
4040
<para>
41-
SQL 标准的正式名称是 ISO/IEC 9075 <quote>数据库语言 SQL</quote>。该标准会不时地发布一个修改的版本，最近一次更新出现在 2011 年。2011 年的版本被称为 ISO/IEC 9075:2011，或者简单地为 SQL:2011。之前的版本是 SQL:2008、SQL:2003、SQL:1999 和 SQL-92。每一个版本会替换之前的一个版本，因此声称与早前的版本相符合没有意义。<productname>PostgreSQL</productname>的开发希望与该标准的最新官方版本相符，并且这种符合不会与额外特性或尝试相冲突。很多 SQL 标准所要求的特性都被支持，不过有时在语法或函数上有所不同。随着时间的推移，符合性会得到进一步的提高。
41+
SQL 标准的正式名称是 ISO/IEC 9075 <quote>数据库语言 SQL</quote>。该标准会不时地发布一个修改的版本，最近一次更新出现在 2016 年。2016年的版本被称为 ISO/IEC 9075:2016，或者简单地为 SQL:2016。之前的版本是 SQL:2011，SQL:2008，SQL:2006，SQL:2003，SQL:1999 和 SQL-92。每一个版本会替换之前的一个版本，因此声称与早前的版本相符合没有意义。<productname>PostgreSQL</productname>的开发希望与该标准的最新官方版本相符，并且这种符合不会与额外特性或尝试相冲突。很多 SQL 标准所要求的特性都被支持，不过有时在语法或函数上有所不同。随着时间的推移，符合性会得到进一步的提高。
4242
</para>
4343

4444
<!--==========================orignal english content==========================
@@ -133,7 +133,7 @@ ____________________________________________________________________________-->
133133
</para>
134134
____________________________________________________________________________-->
135135
<para>
136-
PostgreSQL 支持 SQL:2011 的大部分主要特性。在 179 个完整核心符合所要求的强制特性中，PostgreSQL 至少符合 160 个。另外，还有一个受支持的可选特性的长长的列表。值得注意的是，在编写此文档时，还没有任何数据库管理系统的当前版本声称完全符合核心的 SQL:2011。
136+
PostgreSQL 支持 SQL:2016 的大部分主要特性。在 179 个完整核心符合所要求的强制特性中，PostgreSQL 至少符合 160 个。另外，还有一个受支持的可选特性的长长的列表。值得注意的是，在编写此文档时，还没有任何数据库管理系统的当前版本声称完全符合核心的 SQL:2016。
137137
</para>
138138

139139
<!--==========================orignal english content==========================
@@ -150,7 +150,7 @@ ____________________________________________________________________________-->
150150
</para>
151151
____________________________________________________________________________-->
152152
<para>
153-
在下面的两节中，我们提供了一个<productname>PostgreSQL</productname>所支持特性的列表，以及一个在<acronym>SQL:2011</acronym>中定义却还未被<productname>PostgreSQL</productname>支持的特性的列表。这两个列表都是大概的：对于被列为支持的一个特性可能会有少量的细节不符合，而且大部分未被支持的特性可能事实上已经被实现。本文档的主体部分包含了哪些能用哪些不能用的准确信息。
153+
在下面的两节中，我们提供了一个<productname>PostgreSQL</productname>所支持特性的列表，以及一个在<acronym>SQL:2016</acronym>中定义却还未被<productname>PostgreSQL</productname>支持的特性的列表。这两个列表都是大概的：对于被列为支持的一个特性可能会有少量的细节不符合，而且大部分未被支持的特性可能事实上已经被实现。本文档的主体部分包含了哪些能用哪些不能用的准确信息。
154154
</para>
155155

156156
<note>
@@ -241,7 +241,7 @@ ____________________________________________________________________________-->
241241
</para>
242242
____________________________________________________________________________-->
243243
<para>
244-
下列定义在<acronym>SQL:2011</acronym>中的特性还没有在这个<productname>PostgreSQL</productname>发行中被实现。在一些情况中，有等效的功能可用。
244+
下列定义在<acronym>SQL:2016</acronym>中的特性还没有在这个<productname>PostgreSQL</productname>发行中被实现。在一些情况中，有等效的功能可用。
245245

246246
<informaltable>
247247
<tgroup cols="4">
@@ -261,4 +261,209 @@ ____________________________________________________________________________-->
261261
</para>
262262
</sect1>
263263

264+
<sect1 id="xml-limits-conformance">
265+
<title>XML对于SQL的限制和符合性/XML</title>
266+
267+
<indexterm>
268+
<primary>SQL/XML</primary>
269+
<secondary>限制和符合性</secondary>
270+
</indexterm>
271+
272+
<para>
273+
ISO/IEC 9075-14中与XML相关的规范进行了重大修订
274+
(SQL/XML)与SQL:2006一起被引入.
275+
<productname>PostgreSQL</productname>'s 的XML数据类型和相关函数的实现基本上沿用了2003年的早期版本。有一些借鉴了后来的版本。 特别是:
276+
<itemizedlist>
277+
<listitem>
278+
<para>现行标准提供了一系列可扩展标记语言数据类型，其中将<quote>文档</quote>或<quote>内容</quote>保存在非类型或XML Schema类型的变体，以及类型<type>XML(SEQUENCE)</type>用于保存任意的XML内容片段。
279+
<productname>PostgreSQL</productname>提供了一个单一的<type>xml</type>类型，可以容纳<quote>文档</quote>或<quote>内容</quote>。 没有相应的标准的<quote>序列</quote>类型。
280+
</para>
281+
</listitem>
282+
283+
<listitem>
284+
<para>
285+
<productname>PostgreSQL</productname>提供了两个函数在SQL:2006中引入的，但是在变体中，使用的是XPath 1.0语言，而不是在标准中为其指定的XML查询。
286+
</para>
287+
</listitem>
288+
</itemizedlist>
289+
</para>
290+
291+
<para> 本节介绍了一些你可能会遇到的差异。
292+
</para>
293+
294+
<sect2 id="functions-xml-limits-xpath1">
295+
<title>查询只限于XPath 1.0</title>
296+
297+
<para>
298+
<productname>PostgreSQL</productname>-指定的函数
299+
<function>xpath()</function> 和 <function>xpath_exists()</function>使用XPath语言查询XML文档。
300+
<productname>PostgreSQL</productname>也提供了标准函数中的XPath-only变体<function>XMLEXISTS</function>和
301+
<function>XMLTABLE</function>, 其中正式采用XQuery语言。所有这些函数
302+
<productname>PostgreSQL</productname>都依赖于<application>libxml2</application> 库，而这个库仅在XPath 1.0中提供。
303+
</para>
304+
305+
<para>在XQuery语言和XPath 2.0及以后的版本之间有很强的联系：任何语法上有效的表达式，在这两个版本中都能成功地执行，都会产生相同的结果（对于包含数字字符引用或预定义的实体引用的表达式会略有不同，
306+
XQuery会用相应的字符替换，而 XPath则不会。) 但这些语言和XPath 1.0之间没有这种联系，它是一种较早的语言，在很多方面都有区别。
307+
</para>
308+
309+
<para>有两类限制需要记住：一是对SQL标准中指定的函数从XQuery到XPath的限制，二是对标准和<productname>PostgreSQL</productname>特定函数XPath的限制是1.0版本 。
310+
</para>
311+
312+
<sect3>
313+
<title>XQuery到XPath的限制</title>
314+
<para>
315+
除了XPath的特性之外，XQuery的特性还包括:
316+
<itemizedlist>
317+
<listitem>
318+
<para>
319+
除了所有可能的XPath值之外，XQuery表达式还可以构造和返回新的XML节点。 XPath 可以创建和返回原子类型（数字、字符串等）的值，但只能返回作为表达式输入的文档中已经存在的XML节点。
320+
</para>
321+
</listitem>
322+
323+
<listitem>
324+
<para>
325+
XQuery有用于迭代、排序和分组的控制结构。
326+
</para>
327+
</listitem>
328+
329+
<listitem>
330+
<para>
331+
XQuery允许声明和使用局部函数。
332+
</para>
333+
</listitem>
334+
</itemizedlist>
335+
</para>
336+
337+
<para>
338+
最近的 XPath 版本开始提供与这些功能重叠的功能（例如函数式的 <function>for-each</function>和<function>sort</function>，匿名函数，以及 <function>parse-xml</function>从字符串中创建节点的<function>parse-xml</function>），但这些功能在 XPath 3.0 之前是不具备的。
339+
</para>
340+
</sect3>
341+
342+
<sect3 id="xml-xpath-1-specifics">
343+
<title>对XPath的限制为1.0</title>
344+
345+
<para>
346+
对于熟悉XQuery和XPath 2.0或更高版本的开发人员来说，XPath 1.0带来了许多不同的地方，需要解决的是:
347+
348+
<itemizedlist>
349+
<listitem>
350+
<para>
351+
一个XQuery/XPath表达式的基本类型，即 <type>sequence</type>，它可以包含XML节点、原子值或两者，在XPath 1.0中不存在。一个1.0表达式只能产生一个节点集（包含0个或更多的XML节点），或者一个原子值。
352+
</para>
353+
</listitem>
354+
355+
<listitem>
356+
<para>
357+
与XQuery/XPath序列不同的是，XPath 1.0节点集没有保证顺序，和任何集一样，不允许同一个项目多次出现。
358+
<note>
359+
<para>
360+
<application>libxml2</application>库似乎总是将节点集返回到<productname>PostgreSQL</productname>的节点集，其成员在输入文档中的相对顺序是一样的。 它的文档并没有承诺这种行为，而且XPath 1.0表达式不能控制它。
361+
</para>
362+
</note>
363+
</para>
364+
</listitem>
365+
366+
<listitem>
367+
<para>
368+
虽然XQuery/XPath提供了XML Schema中定义的所有类型和许多操作符和函数，但XPath 1.0只有节点集和三种原子类型<type>boolean</type>、<type>double</type>和<type>string</type>。
369+
</para>
370+
</listitem>
371+
372+
<listitem>
373+
<para>
374+
XPath 1.0没有条件运算符。一个XQuery/XPath表达式，如<literal>if ( hat ) then hat/@size else "no hat"</literal>没有XPath 1.0的等价物。
375+
</para>
376+
</listitem>
377+
378+
<listitem>
379+
<para>
380+
XPath 1.0没有对字符串进行排序比较运算符。<literal>"cat" &lt; "dog"</literal>和<literal>"cat" &gt; "dog"</literal>都是假的，因为每一个都是两个<literal>NaN</literal>的数值比较。相比之下，<literal>=</literal>和<literal>!!=</literal>确实将字符串作为字符串进行比较。
381+
</para>
382+
</listitem>
383+
384+
<listitem>
385+
<para>
386+
XPath 1.0模糊了XQuery/XPath定义的<firstterm>值比较</firstterm>和<firstterm>一般比较</firstterm>之间的区别。 <literal>sale/@hatsize = 7</literal>和<literal>sale/@customer = "alice"</literal>都是存在的量化比较，如果有任何<literal>sale</literal>属性的给定值，则为真。但<literal>sale/@taxable = false()</literal>是与整个节点集的<firstterm>有效布尔值</firstterm>的值比较。只有当没有<literal>sale</literal>有一个<literal>taxable</literal>属性时，它才是真值。
387+
</para>
388+
</listitem>
389+
390+
<listitem>
391+
<para>
392+
在XQuery/XPath数据模型中，一个<firstterm>文档节点</firstterm>既可以有文档形式（即正好有一个顶层元素，只有注释和处理指令以外的注释和处理指令），也可以有内容形式（放宽了这些限制）。在XPath 1.0中，它的等价物是<firstterm>根节点</firstterm>，只能是文档形式。这也是<type>xml</type>的值被作为 上下文项到任何 <productname>PostgreSQL</productname>的上下文项 基于XPath的函数必须是以文档形式出现。
393+
</para>
394+
</listitem>
395+
</itemizedlist>
396+
</para>
397+
398+
<para>
399+
这里强调的区别并不是全部。在XQuery和XPath的2.0及以后的版本中，有一个XPath 1.0的兼容性模式，W3C列出的 <ulink url='https://www.w3.org/TR/2010/REC-xpath-functions-20101214/#xpath1-compatibility'>函数库变化</ulink>和<ulink url='https://www.w3.org/TR/xpath20/#id-backwards-compatibility'>语言变化</ulink>在该模式下应用的列表提供了一个更完整（但仍然不是详尽的）的差异说明。 兼容性模式不能使后来的语言与XPath 1.0完全等同。
400+
</para>
401+
</sect3>
402+
403+
<sect3 id="functions-xml-limits-casts">
404+
<title>SQL和XML数据类型和值之间的映射</title>
405+
406+
<para>
407+
在SQL:2006及以后的版本中，标准SQL数据类型和XML Schema类型之间的转换方向都被精确地指定了。但是，这些规则都是用XQuery/XPath的类型和语义来表示的，对于XPath 1.0的不同数据模型没有直接应用。
408+
</para>
409+
410+
<para>
411+
当<productname>PostgreSQL</productname>将SQL数据值映射到XML（如<function>xmlelement</function>），或XML映射到SQL（如输出 <function>xmltable</function>的列)，除了少数情况下的 特殊处理，<productname>PostgreSQL</productname>只需假定 XML 数据类型的 XPath 1.0 字符串形式将被视为有效的文本输入形式的SQL数据类型，反之。 该规则的优点是简单，同时对许多数据类型来说，产生的结果与标准中规定的映射类似。
412+
</para>
413+
414+
<para>
415+
如果与其他系统的互操作性是一个问题，对于某些数据类型，可能需要使用数据类型格式化函数（如<xref linkend="function-formatting"/>中的函数）来生成标准映射。
416+
</para>
417+
</sect3>
418+
</sect2>
419+
420+
<sect2 id="functions-xml-limits-postgresql">
421+
<title>
422+
实现中的偶然限制
423+
</title>
424+
425+
<para>
426+
本节涉及的限制并不是<application>libxml2</application>库所固有的，而是适用于<productname>PostgreSQL</productname>中的当前实现。
427+
</para>
428+
429+
<sect3>
430+
<title>仅支持<literal>by VALUE</literal>传递机制</title>。
431+
432+
<para>
433+
SQL标准定义了两种<firstterm>传递机制</firstterm>，适用于从SQL向XML函数传递XML参数或接收结果时。<literal>BY REF</literal>，其中一个特定的XML
434+
值保留其节点身份，以及<literal>BY VALUE</literal>，其中传递XML的内容，但不保留节点身份。可以在参数列表之前指定，作为所有参数的默认机制，也可以在任何参数之后指定，以覆盖默认机制。
435+
</para>
436+
437+
<para>
438+
为了说明区别，如果<replaceable>x</replaceable>是一个XML值，那么在SQL:2006环境下的这两个查询将分别产生true和false。
439+
440+
<programlisting>
441+
SELECT XMLQUERY('$a is $b' PASSING BY REF <replaceable>x</replaceable> AS a, <replaceable>x</replaceable> AS b NULL ON EMPTY);
442+
SELECT XMLQUERY('$a is $b' PASSING BY VALUE <replaceable>x</replaceable> AS a, <replaceable>x</replaceable> AS b NULL ON EMPTY);
443+
</programlisting>
444+
</para>
445+
446+
<para>
447+
<productname>PostgreSQL</productname>将在<function>XMLEXISTS</function>或<function>XMLTABLE</function>构造中接受<literal>BY VALUE</literal>或<literal>BY REF</literal>，但它会忽略它们。 <type>xml</type>数据类型持有一个字符串的序列化表示，因此没有节点标识需要保留，并且传递总是有效的<literal>BY VALUE</literal>。
448+
</para>
449+
</sect3>
450+
451+
<sect3>
452+
<title>不能将命名的参数传递到查询中</title>
453+
454+
<para>
455+
基于 XPath 的函数支持传递一个参数作为 XPath 表达式的上下文项，但不支持传递额外的值作为命名参数提供给表达式。
456+
</para>
457+
</sect3>
458+
459+
<sect3>
460+
<title>无 <type>XML(SEQUENCE)</type>类型</title>类型
461+
462+
<para>
463+
<productname>PostgreSQL</productname> <type>xml</type>数据类型只能保存一个值，在<literal>DOCUMENT</literal>或 <literal>CONTENT</literal>形式。 一个XQuery/XPath表达式上下文项必须是一个单一的XML节点或原子值，但XPath 1.0进一步限制它只能是一个XML节点，并且没有允许<literal>CONTENT</literal>的节点类型。 最终的结果是，一个完善的<literal> DOCUMENT </literal>是<productname> PostgreSQL</productname>可以作为XPath上下文项提供的唯一形式的XML值。
464+
</para>
465+
</sect3>
466+
</sect2>
467+
</sect1>
468+
264469
</appendix>

0 commit comments

Comments
 (0)