Sorry for the self-reply but I figured it'd be helpful to add information
that I discovered only after my initial post.
On May30, 2011, at 15:17 , Florian Pflug wrote:
> The XPath expression 'name(/*)', for example, is supposed to return 'root'
> when applied to the XML fragment '<root><nested/><nested/></root>'. Postgres,
> however, currently returns an empty array.
In the mean while, I've discovered that this was discussed previously about
a year ago here: http://archives.postgresql.org/pgsql-general/2010-07/msg00355.php
The basic confusion seems to be whether XPATH() is supposed to work on
everything that http://www.w3.org/TR/xpath/ consideres to be an "Expression",
or only on what that document calls a "Location Path".
The difference is basically that "Location Paths" server purely as
predicates, i.e. *select* a subset of nodes from an XML fragment, while
"Expressions" can produce node sets *or* arbitrary scalar values
(boolean, numeric or string).
According to the thread from last summer, XLST handles this by defining
*two* constructs which evaluate XPath expressions, one for those which
return node sets (<xsl:template match="...">) and one for those which
return scalar values (<xsl:value-of select="...">).
My patch makes XPATH() work for both nodset-returning
*and* scalar-value-returning expressions. This has the advantage
of being simpler, but it does force the scalar values produced
by an XPath expression to be valid XML fragments. For boolean and
numeric values this isn't a problem, but it does limit what you
can do with string-returning XPath expressions.
If people deem this to be a problem, we could instead add a separate
function XPATH_VALUE() that returns VARCHAR, and make people use that
for scalar-value-returning expressions. However, to avoid confusion,
XPATH() should then be taught to raise an error if used for scalar-value
returning expressions, instead of silently returning an empty array as
it does now.
Thoughts, anyone?
best regards,
Florian Pflug