Re: [PATCH] Bug in XPATH() if expression returns a scalar value

On Tue, May 31, 2011 at 04:19:29PM +0200, Florian Pflug wrote:
> 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?

I think it's important to note here that the nodeset returning nature of
XPATH in XSLT is a context setting functionality: these nodes are then
further processed by the template. In the postgresql case, the
distinction between returning a value and doing further processing isn't
so clear. My one use-cases tend toward processing a table full of
records with an XML field, using the XPATH to select out fragments and
records ids into a secondary table for further processing/analysis.

What you describe, making XPATH return something for the scalar
functions, is sorely needed. Constraining the return values to be valid
XML fragments is the sort of wart that makes XML processing in
postgresql seem odd to those familiar with other tools, though. How
about naming the other function XPATH_VALUE_OF, just to make it the XSLT
connection clear?

Ross
--
Ross Reedstrom, Ph.D. reedstrm(at)rice(dot)edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
Connexions http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE