On Mar 20, 2009, at 8:56 AM, Andrew Dunstan wrote:
Andrew Dunstan wrote:
A "/" at the beginning of a path expression is an abbreviation for
the initial step fn:root(self::node()) treat as document-node()/
(however, if the "/" is the entire path expression, the trailing
"/"
is omitted from the expansion.) The effect of this initial step is
to begin the path at the root node of the tree that contains the
context node. If the context item is not a node, a type error is
raised [err:XPTY0020]. At evaluation time, if the root node above
the context node is not a document node, a dynamic error is raised
[err:XPDY0050].
The problem is that we certainly do have to provide a context node
(the standard is clear about that), and unless we want to convert a
non-document to a node-set as James suggested and then apply the
xpath expression to each node in the node-set, we have no way of
sanely specifying the context node.
libxml2 only supports xpath1. Why are you referencing xpath20? And, if
SQL-XML requires an xpath20 conforming xpath() function, we have
bigger problems than "'/x' + xpath_str". ;)
Although, this is not terribly important to me as:
No-one has come up with an answer to this,
I don't feel fragment()/node-set() is a good idea from a usability
standpoint alone. I only mentioned it because that's how I've always
worked with fragments in the xslt1 world.. Mere curiosity drove most
of the remaining interest I had in it.
so I propose to remove the hackery.
I think this would probably be best for the core xpath() function.
However, it may be wise to relocate the munging functionality into
another function so users don't have invent their own when they feel
so inclined to work with fragments.
raise an error?
+1, "xpath requires a well-formed document"
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
