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...
pg_xpath_returnvalue.v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers