Re: [PATCH] Bug in XPATH() if expression returns a scalar value - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: [PATCH] Bug in XPATH() if expression returns a scalar value
Date
Msg-id 90EF0E6F-04BC-4CBF-9EE6-44A1CBBE56CB@phlo.org
Whole thread Raw
In response to Re: [PATCH] Bug in XPATH() if expression returns a scalar value  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Jun13, 2011, at 21:24 , Peter Eisentraut wrote:
> On ons, 2011-06-08 at 10:14 +0200, Florian Pflug wrote:
>> But then you lose the ability to evaluate user-supplied
>> XPath expressions, because there's no way of telling which of these
>> function to use.
>
> Perhaps having both variants, one type-safe and one not, would work.  I
> don't agree with doing away with type-safety completely for the sake of
> convenience.

In theory, I agree.

In practice, however, XPath 1.0 isn't very strongly typed itself. The
built-in types are all auto-converted into one another (As if
string(), number(), boolean() had been called). Also, only three of
the functions defined by XPath 1.0 seem interesting. Here's the break-down

The functions returning "string" are string(): Converts arbitrary values to strings local-name(): Name of node-set's
firsttop-level w/o namespace prefix namespace-uri(): Namespace of node-set's first top-level name(): Namespace prefix
andname of node-set's first top-level node concat() starts-with() contains() substring-before() substring-after()
substring()string-length() translate()  
For all of these function postgres provides corresponding SQL functions,
which the exception of local-name() namespace-uri() name()

In fact, these three functions are the raison d'être for my patch and this thread.
I needed to find the name of a tag returned by an XPath expression, and to my
dismay discovered that XPATH('local-name(...)', ...) returns an empty array. The
only reason I added support for boolean and numeric XPath expressions at all was
for the sake of completeness.

Here's the rest of the functions defined by XPath 1.0. I'm convinces that none
of them are particularly useful as top-level functions, and therefore believe
that adding XPATH_BOOLEAN() and XPATH_NUMBER() is largely overkill.

The functions returning "number" are number(): Converts arbitrary values to numbers last() position() count() sum():
Sumover a node-set after implicit conversion of nodes to numbers floor() ceiling() round() operators +, -, *, div, mod 

The functions returning "boolean" are boolean(): Converts arbitrary to boolean not() true() false() operators or, and,
=,!=, <=, <, >=, > 

best regards,
Florian Pflug




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SSI patch renumbered existing 2PC resource managers??
Next
From: Florian Pflug
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY