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

Re: xpath processing brain dead

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, 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 20:18:45
Message-ID: 49A6F925.1030907@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
>> What I have proposed for 8.3 should not break a single case that currently
>> behaves usefully. If anyone has a counter-example please show it.
>>
>> What I have proposed for 8.4 possibly would break current "useful" behaviour
>> (FSVO "useful"), but should be done anyway on correctness grounds.
>>     
>
> I dunno, aren't XML document fragments sort of a pretty common case?
>
>
>   

They are. So what? How does that contradict either of the statements 
made above?

Programmers using libxml2 are used to handling this problem. Why must 
postgres alone use a totally brain dead and utterly incorrect wrapping 
to solve a problem that everyone else leaves up to the programmer to handle?

People in this thread are not concentrating on the fact that what we do 
now can break correct input. That makes it an unquestionable bug, 
IMNSHO. There seems to be agreement about what to do for 8.4, so we seem 
to be arguing about what to do for 8.3. Are you *really* arguing that 
prepending the xpath expression with '/x' in all cases should be allowed 
to continue? If you are I can only assume your use of xml/xpath is 
probably fairly light.

cheers

andrew



In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-02-26 20:37:26
Subject: Re: xpath processing brain dead
Previous:From: Bryce CuttDate: 2009-02-26 20:16:42
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets

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