ne 30. 12. 2018 v 20:06 odesÃlatel Chapman Flack <c...@anastigmatix.net> napsal:
> 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: > > +1 > - 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. > This is difficult question - a implementation is probably very easy, but it is hard to accept to possible break compatibility due syntactic sugar. This is not probably related to just XPath/XQuery question - but it is related to different design of XML datatype (based on PostgreSQL TOAST) against ANSI/SQL (Oracle - clob). So this is complicated topic and my opinion is better to don't touch it because we can't to fix it, change it - and I am not sure so ANSI/SQL is significantly better than PostgreSQL implementation. > > -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 >
