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
