On May31, 2011, at 19:15 , Ross J. Reedstrom wrote:
> 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.
I've now changes things so that the results of scalar-value
returning XPath expressions are correctly entity-encoded (i.e.,
a literal "<" gets translated to "<").
After realizing that this is necessary even for node-set
returning XPath expressions (see my other mail from today),
because they may very well select text nodes, I came to the
conclusion that doing this unconditionally (well, except for
element nodes obviously) is the least surprising behaviour.
The following subsumes the behavior with this and the patch
from my other e-mail applied.
SELECT
(XPATH('namespace-uri(/*)', x))[1] AS namespace,
(XPATH('/*/@value', x))[1] AS value,
(XPATH('/*/text()', x))[1] AS text
FROM (VALUES (XMLELEMENT(name "root",
XMLATTRIBUTES('<n' AS xmlns, '<v' AS value),
'<t'
))) v(x);
namespace | value | text
-----------+-------+-------
<n | <v | <t
Without the patch from the other mail, the "namespace" result
stays the same, but "value" and "text" are "<v" and "<t"
respectively.
Updated patch is attached
best regards,
Florian Pflug
PS: Btw, while trying this I think I found another problem. If you
do
SELECT (XPATH(
'/*',
XMLELEMENT(NAME "root",
XMLATTRIBUTES('<n' AS xmlns,
'<v' AS value))
))[1];
you get
xpath
----------------------------------
<root xmlns="<n" value="<v"/>
i.e. the "<" in the namespace URI isn't quoted properly.
Trying to cast that value to text and back to xml fails.
Funnily enough, if you skip the XPATH() call, things work properly
SELECT XMLELEMENT(NAME "root",
XMLATTRIBUTES('<n' AS xmlns,
'<v' AS value))
gives
xmlelement
-------------------------------------
<root xmlns="<n" value="<v"/>
I'll start a new thread for this issue...
