begriffs open source - ai-pg/blob - full-docs/txt/xml-limits-conformance.txt

   1
   2 D.3. XML Limits and Conformance to SQL/XML #
   3
   4    D.3.1. Queries Are Restricted to XPath 1.0
   5    D.3.2. Incidental Limits of the Implementation
   6
   7    Significant revisions to the XML-related specifications in ISO/IEC
   8    9075-14 (SQL/XML) were introduced with SQL:2006. PostgreSQL's
   9    implementation of the XML data type and related functions largely
  10    follows the earlier 2003 edition, with some borrowing from later
  11    editions. In particular:
  12      * Where the current standard provides a family of XML data types to
  13        hold “document” or “content” in untyped or XML Schema-typed
  14        variants, and a type XML(SEQUENCE) to hold arbitrary pieces of XML
  15        content, PostgreSQL provides the single xml type, which can hold
  16        “document” or “content”. There is no equivalent of the standard's
  17        “sequence” type.
  18      * PostgreSQL provides two functions introduced in SQL:2006, but in
  19        variants that use the XPath 1.0 language, rather than XML Query as
  20        specified for them in the standard.
  21      * PostgreSQL does not support the RETURNING CONTENT or RETURNING
  22        SEQUENCE clauses, functions which are defined to have these in the
  23        specification are implicitly returning content.
  24
  25    This section presents some of the resulting differences you may
  26    encounter.
  27
  28 D.3.1. Queries Are Restricted to XPath 1.0 #
  29
  30    The PostgreSQL-specific functions xpath() and xpath_exists() query XML
  31    documents using the XPath language. PostgreSQL also provides XPath-only
  32    variants of the standard functions XMLEXISTS and XMLTABLE, which
  33    officially use the XQuery language. For all of these functions,
  34    PostgreSQL relies on the libxml2 library, which provides only XPath
  35    1.0.
  36
  37    There is a strong connection between the XQuery language and XPath
  38    versions 2.0 and later: any expression that is syntactically valid and
  39    executes successfully in both produces the same result (with a minor
  40    exception for expressions containing numeric character references or
  41    predefined entity references, which XQuery replaces with the
  42    corresponding character while XPath leaves them alone). But there is no
  43    such connection between these languages and XPath 1.0; it was an
  44    earlier language and differs in many respects.
  45
  46    There are two categories of limitation to keep in mind: the restriction
  47    from XQuery to XPath for the functions specified in the SQL standard,
  48    and the restriction of XPath to version 1.0 for both the standard and
  49    the PostgreSQL-specific functions.
  50
  51 D.3.1.1. Restriction of XQuery to XPath #
  52
  53    Features of XQuery beyond those of XPath include:
  54      * XQuery expressions can construct and return new XML nodes, in
  55        addition to all possible XPath values. XPath can create and return
  56        values of the atomic types (numbers, strings, and so on) but can
  57        only return XML nodes that were already present in documents
  58        supplied as input to the expression.
  59      * XQuery has control constructs for iteration, sorting, and grouping.
  60      * XQuery allows declaration and use of local functions.
  61
  62    Recent XPath versions begin to offer capabilities overlapping with
  63    these (such as functional-style for-each and sort, anonymous functions,
  64    and parse-xml to create a node from a string), but such features were
  65    not available before XPath 3.0.
  66
  67 D.3.1.2. Restriction of XPath to 1.0 #
  68
  69    For developers familiar with XQuery and XPath 2.0 or later, XPath 1.0
  70    presents a number of differences to contend with:
  71      * The fundamental type of an XQuery/XPath expression, the sequence,
  72        which can contain XML nodes, atomic values, or both, does not exist
  73        in XPath 1.0. A 1.0 expression can only produce a node-set
  74        (containing zero or more XML nodes), or a single atomic value.
  75      * Unlike an XQuery/XPath sequence, which can contain any desired
  76        items in any desired order, an XPath 1.0 node-set has no guaranteed
  77        order and, like any set, does not allow multiple appearances of the
  78        same item.
  79
  80 Note
  81        The libxml2 library does seem to always return node-sets to
  82        PostgreSQL with their members in the same relative order they had
  83        in the input document. Its documentation does not commit to this
  84        behavior, and an XPath 1.0 expression cannot control it.
  85      * While XQuery/XPath provides all of the types defined in XML Schema
  86        and many operators and functions over those types, XPath 1.0 has
  87        only node-sets and the three atomic types boolean, double, and
  88        string.
  89      * XPath 1.0 has no conditional operator. An XQuery/XPath expression
  90        such as if ( hat ) then hat/@size else "no hat" has no XPath 1.0
  91        equivalent.
  92      * XPath 1.0 has no ordering comparison operator for strings. Both
  93        "cat" < "dog" and "cat" > "dog" are false, because each is a
  94        numeric comparison of two NaNs. In contrast, = and != do compare
  95        the strings as strings.
  96      * XPath 1.0 blurs the distinction between value comparisons and
  97        general comparisons as XQuery/XPath define them. Both sale/@hatsize
  98        = 7 and sale/@customer = "alice" are existentially quantified
  99        comparisons, true if there is any sale with the given value for the
 100        attribute, but sale/@taxable = false() is a value comparison to the
 101        effective boolean value of a whole node-set. It is true only if no
 102        sale has a taxable attribute at all.
 103      * In the XQuery/XPath data model, a document node can have either
 104        document form (i.e., exactly one top-level element, with only
 105        comments and processing instructions outside of it) or content form
 106        (with those constraints relaxed). Its equivalent in XPath 1.0, the
 107        root node, can only be in document form. This is part of the reason
 108        an xml value passed as the context item to any PostgreSQL
 109        XPath-based function must be in document form.
 110
 111    The differences highlighted here are not all of them. In XQuery and the
 112    2.0 and later versions of XPath, there is an XPath 1.0 compatibility
 113    mode, and the W3C lists of function library changes and language
 114    changes applied in that mode offer a more complete (but still not
 115    exhaustive) account of the differences. The compatibility mode cannot
 116    make the later languages exactly equivalent to XPath 1.0.
 117
 118 D.3.1.3. Mappings between SQL and XML Data Types and Values #
 119
 120    In SQL:2006 and later, both directions of conversion between standard
 121    SQL data types and the XML Schema types are specified precisely.
 122    However, the rules are expressed using the types and semantics of
 123    XQuery/XPath, and have no direct application to the different data
 124    model of XPath 1.0.
 125
 126    When PostgreSQL maps SQL data values to XML (as in xmlelement), or XML
 127    to SQL (as in the output columns of xmltable), except for a few cases
 128    treated specially, PostgreSQL simply assumes that the XML data type's
 129    XPath 1.0 string form will be valid as the text-input form of the SQL
 130    datatype, and conversely. This rule has the virtue of simplicity while
 131    producing, for many data types, results similar to the mappings
 132    specified in the standard.
 133
 134    Where interoperability with other systems is a concern, for some data
 135    types, it may be necessary to use data type formatting functions (such
 136    as those in Section 9.8) explicitly to produce the standard mappings.
 137
 138 D.3.2. Incidental Limits of the Implementation #
 139
 140    This section concerns limits that are not inherent in the libxml2
 141    library, but apply to the current implementation in PostgreSQL.
 142
 143 D.3.2.1. Only BY VALUE Passing Mechanism Is Supported #
 144
 145    The SQL standard defines two passing mechanisms that apply when passing
 146    an XML argument from SQL to an XML function or receiving a result: BY
 147    REF, in which a particular XML value retains its node identity, and BY
 148    VALUE, in which the content of the XML is passed but node identity is
 149    not preserved. A mechanism can be specified before a list of
 150    parameters, as the default mechanism for all of them, or after any
 151    parameter, to override the default.
 152
 153    To illustrate the difference, if x is an XML value, these two queries
 154    in an SQL:2006 environment would produce true and false, respectively:
 155 SELECT XMLQUERY('$a is $b' PASSING BY REF x AS a, x AS b NULL ON EMPTY);
 156 SELECT XMLQUERY('$a is $b' PASSING BY VALUE x AS a, x AS b NULL ON EMPTY);
 157
 158    PostgreSQL will accept BY VALUE or BY REF in an XMLEXISTS or XMLTABLE
 159    construct, but it ignores them. The xml data type holds a
 160    character-string serialized representation, so there is no node
 161    identity to preserve, and passing is always effectively BY VALUE.
 162
 163 D.3.2.2. Cannot Pass Named Parameters to Queries #
 164
 165    The XPath-based functions support passing one parameter to serve as the
 166    XPath expression's context item, but do not support passing additional
 167    values to be available to the expression as named parameters.
 168
 169 D.3.2.3. No XML(SEQUENCE) Type #
 170
 171    The PostgreSQL xml data type can only hold a value in DOCUMENT or
 172    CONTENT form. An XQuery/XPath expression context item must be a single
 173    XML node or atomic value, but XPath 1.0 further restricts it to be only
 174    an XML node, and has no node type allowing CONTENT. The upshot is that
 175    a well-formed DOCUMENT is the only form of XML value that PostgreSQL
 176    can supply as an XPath context item.