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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers