Skip site navigation (1) Skip section navigation (2)

Re: xpath processing brain dead

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
Subject: Re: xpath processing brain dead
Date: 2009-02-26 17:07:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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

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.



In response to


pgsql-hackers by date

Next:From: Lawrence, RamonDate: 2009-02-26 17:08:34
Subject: Re: Proposed Patch to Improve Performance ofMulti-BatchHash Join for Skewed Data Sets
Previous:From: Lawrence, RamonDate: 2009-02-26 16:52:37
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group