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

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Bug in XPATH() if expression returns a scalar value
Date: 2011-06-14 09:56:31
Message-ID: 90EF0E6F-04BC-4CBF-9EE6-44A1CBBE56CB@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 first top-level w/o namespace prefix
namespace-uri(): Namespace of node-set's first top-level
name(): Namespace prefix and name 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(): Sum over 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-06-14 10:05:45 Re: Boolean operators without commutators vs. ALL/ANY
Previous Message Heikki Linnakangas 2011-06-14 09:40:32 Re: SSI patch renumbered existing 2PC resource managers??