Re: XMLDocument (SQL/XML X030)

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Chapman Flack <jcflack(at)acm(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Treat <rob(at)xzilla(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: XMLDocument (SQL/XML X030)
Date: 2025-01-24 19:59:11
Message-ID: 422f222f-e51f-43fa-9b82-2b5fa6a92528@uni-muenster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

On 24.01.25 17:18, Chapman Flack wrote:
> Or even: ... An XML Query "document node" is a relaxed version
> of XML document structure that corresponds exactly to what
> PostgreSQL's one XML type is already allowed to contain, so
> any non-null PostgreSQL XML value can be returned unchanged.
> More-permissive XML types some systems offer may hold values
> that are not so structured.

I think this version is much clearer and contains all the points that
were mentioned by Pavel earlier in this thread. Thanks for that!

I made some minor adjustments and added in v5 (attached)

---------------

The <function>xmldocument</function> function returns the input argument
unchanged, or <literal>NULL</literal> if the argument is
<literal>NULL</literal>, and is provided for compatibility.

In the XML Query standard, a "document node" represents a relaxed
version of an XML document structure. This corresponds to what
PostgreSQL's single XML type allows, meaning that any valid non-null
PostgreSQL XML value can be returned unchanged. Other systems may
support more permissive XML data types, such as
<literal>XML(SEQUENCE)</literal>, which allow values that do not conform
to this structure. In PostgreSQL, every valid non-null value of the XML
type already has that structure, making any additional processing by
this function unnecessary.

-------------------

Is it ok like this?

Best regards, Jim

Attachment Content-Type Size
v5-0001-Add-XMLDocument-function-SQL-XML-X030.patch text/x-patch 11.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-01-24 20:02:21 Re: Eagerly scan all-visible pages to amortize aggressive vacuum
Previous Message Tom Lane 2025-01-24 19:56:45 Re: BF member drongo doesn't like 035_standby_logical_decoding.pl