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
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?? |