Re: PostgreSQL vs SQL/XML Standards

On 02/01/19 20:20, Michael Paquier wrote:
> On Thu, Jan 31, 2019 at 04:26:31PM +0100, Pavel Stehule wrote:
>> I'll mark this patch as ready for commiters.
>
> For now I have moved the patch to the next CF, with the same status.

I wonder whether, given the move to next CF, it makes sense to change
the title of the CF entry from "XMLTABLE" to, more generically, XML
improvements, and get one or two more small changes in:

- get XMLPARSE(CONTENT... (and cast-to-xml with XMLOPTION=content) to
succeed even for content with DTDs, so that the content subtype really
does fully include the document subtype, aligning it with the SQL:2006+
standard. I think this would be a simple patch that I can deliver early
this month, and Tom found reports where the current behavior already
bites people in pg_restore. Its only effect would be to allow a currently-
failing case to succeed (and stop biting people).

- get XMLEXISTS and XMLTABLE to allow passing of named parameters. I have
less of a sense of how difficult that might be, but I see that the libxml
xpath API does allow them. I don't know whether they were left out of the
original development just arbitrarily, or whether some effort was made
and ran into some problem.

The value of supporting the named parameters, especially when the library
limits us to XPath 1.0, is that the XPath 1.0 limitation that a value
passed as the context item can only be an XML 'document' only applies to
the context item, not to named parameters. So if somebody is trying to
port an expression ...'foo(.)' PASSING bar... and bar is not in document
form, there's a simple rewrite to ...'foo($a) PASSING bar AS a...
whereas if we can't do named parameters, frustration ensues.

Again, the only effect of such a change would be to permit something that
currently isn't possible. I don't think I can promise to work on a patch
for the second issue, but they both seem worthwhile, and I'm happy to
work on the first.

It seems to me these changes and the doc patch to go with them are
closely enough related to fit in one CF entry that's still smaller and
simpler than many, and that shouldn't be too difficult to review for v12,
but I'll defer to more experienced voices.

Regards,
-Chap