Peter Eisentraut wrote:
> Andrew Dunstan wrote:
>> For fear of passing an ill formed fragment of xml to the processor,
>> we strip the xml declaration if any and surround what's left with
>> '<x>" and '</x>' and prepend '/x' to the supposed xpath. This is just
>> horrible. It will break for every xpath expression that doesn't begin
>> with a '/' and probably for many that do.
>>
>> This whole thing is a mess, and I suspect the only fix for now is to
>> undo all the mangling of both the xml and the xpath expression. If
>> the programmer passes an ill formed piece of xml to the processor
>> that is their lookout, but I think we should ensure that we give back
>> correct results on well formed input.
>
> It's not about ill-formed pieces, it is about (well-formed) content
> fragments that are not full documents (exactly one root element).
> libxml2 doesn't support xpath on content fragments.
>
> The tradeoff here is either supporting no xpath at all on content
> fragments or supporting some xpath on both kinds of xml data. Whoever
> made the initial implementation of this (Nikolay, Cc) decided for the
> latter, but I can't say I'm happy with it either. I'd be OK with
> changing it, but I haven't had time to get to it, unfortunately.
>
> See also <http://wiki.postgresql.org/wiki/XPath_Todo#XPath>.
I don't think it is our responsibility to remedy the deficiencies of
libxml2, especially if it involves breaking the processing of valid
xpath expressions on well formed XML.
If someone can come up with a correct scheme for handling fragments, I'm
all ears, but otherwise I think a) we should rip this out of 8.4 and b)
we should try to make 8.3 slightly less broken at least, along the lines
of my earlier suggestion.
cheers
andrew