XML type

Use XMLPARSE

XMLPARSE is the SQL-standard function for converting a string to an XML value:

XMLPARSE ( { DOCUMENT | CONTENT } value )

Examples:

-- Parse a full XML document
XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title><chapter>...</chapter></book>')

-- Parse a content fragment
XMLPARSE (CONTENT 'abc<foo>bar</foo><bar>foo</bar>')

Use PolarDB-specific cast syntax

PolarDB for PostgreSQL (Compatible with Oracle) also supports these shorthand forms:

xml '<foo>bar</foo>'
'<foo>bar</foo>'::xml

Validation behavior

The XML type does not validate input against a document type declaration (DTD), even if the input specifies one. There is no built-in support for validation against other XML schema languages such as XML Schema.

Control the DOCUMENT or CONTENT mode

When casting between strings and XML values without using XMLPARSE or XMLSERIALIZE, the XML option session parameter controls whether the value is treated as DOCUMENT or CONTENT. Set it using either command:

-- SQL-standard command
SET XML OPTION { DOCUMENT | CONTENT };

-- PolarDB-specific command
SET xmloption TO { DOCUMENT | CONTENT };

The default is CONTENT, which accepts all forms of XML data.

Text mode (default)

In text mode, PolarDB converts all character data between the client and server to the destination's character encoding. This means:

• Encoding declarations in XML data may become invalid after conversion.

• The system ignores encoding declarations in character strings passed to the XML type and assumes content is in the current server encoding.

• Send XML data in the current client encoding, or convert documents to the client encoding before sending.

On output, XML values carry no encoding declaration, and the client assumes all data is in the current client encoding.

Binary mode

In binary mode, no encoding conversion is performed. The system observes encoding declarations in the XML data. If no declaration is present, data is assumed to be in UTF-8, as required by the XML standard.

PolarDB for PostgreSQL (Compatible with Oracle) does not support UTF-16.

On output, data includes an encoding declaration specifying the client encoding — unless the client encoding is UTF-8, in which case the declaration is omitted.

Encoding recommendations

XML data processing is least error-prone and most efficient when the XML data encoding, client encoding, and server encoding are all the same. Computations are most efficient when the server encoding is UTF-8, because XML is processed internally in UTF-8.