On 12/30/18 03:23, Pavel Stehule wrote: > I agree with more stronger detail description about difference between > XPath, XPath2 and XQuery. > > Some like "The XPath 1.0 is ancestor of XPath 2.0, that is part of XQuery. > ..."
I'll be happy to work on some wording to help detail the differences. I don't think it can be condensed to a single sentence, or even if it could, it would not serve users well; what's helpful is to know the specifics of what changed between XPath 1.0 and the 2.0-3.0-3.1 lineage that is now XPath, because that's what helps to understand what the challenges will be when porting queries from other systems, how to recognize when a query won't be possible to port at all, etc. So I think it needs to be a short section. I am still undecided what's the best place in the manual for the section to go: - Added to the introductory material under functions-xml - A long <footnote> attached to a short remark in that introductory matter (is there any precedent? I see there are <footnote>s already in the manual, but I haven't checked how long they get) - A new appendix (or new section in the SQL Conformance appendix) linked from a short statement in the functions-xml introductory matter. > I don't think so link to wiki with any proposals is good idea. That makes sense. I was thinking only of linking directly to the specific section on XPath 1.0 compatibility issues, not to the wiki page as a whole. I see in grepping through the *.sgml that there are not many links to the wiki.postgresql.org, and the ones that exist are only in release notes, Further Information, The Source Code Repository, and sepgsql. So precedent seems to stand against using a link to the wiki section. So, the material /in/ that wiki section [1] (but omitting the two paras about the DOCUMENT/CONTENT node-wrapping hack) is more or less what needs to go into the new section in the manual. I assume it's ok to directly include links [2] and [3] out to the w3.org compatibility notes ... those are stable URLs to reference material. === BY REF and BY VALUE === How difficult would it be to make the grammar constructs that currently accept "BY REF" (only as noise and ignore it) accept and ignore both BY REF and BY VALUE? The documentation ought to state that, while both forms are accepted and ignored, PostgreSQL's actual behavior corresponds to what the standard calls BY VALUE (using a string serialization as the XML datatype's internal form makes the BY REF semantics impossible). So it's when people try to port queries that explicitly say BY REF that they need to know there may be trouble ahead. -Chap >> [1] >> https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL/XML_Standards#Related_to_version_of_XPath >> [2] https://www.w3.org/TR/xpath20/#id-backwards-compatibility >> [3] >> https://www.w3.org/TR/2010/REC-xpath-functions-20101214/#xpath1-compatibility
