Re: xmlconcat (was 9.0 release notes done)

Поиск
Список
Период
Сортировка
Искать
От
Andrew Dunstan
Тема
Re: xmlconcat (was 9.0 release notes done)
Дата
Msg-id
4BA65236.101@dunslane.net
Ответ на
Список
Дерево обсуждения
Re: 9.0 release notes done Bruce Momjian <bruce@momjian.us>
Re: 9.0 release notes done Robert Haas <robertmhaas@gmail.com>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Bruce Momjian <bruce@momjian.us>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Peter Eisentraut <peter_e@gmx.net>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Magnus Hagander <magnus@hagander.net>
Re: 9.0 release notes done David Fetter <david@fetter.org>
Re: 9.0 release notes done Bruce Momjian <bruce@momjian.us>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Bruce Momjian <bruce@momjian.us>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Josh Berkus <josh@agliodbs.com>
Re: 9.0 release notes done Bruce Momjian <bruce@momjian.us>


Tom Lane wrote:
> Andrew Dunstan  writes:
>   
>>> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
>>>       
>
>   
>> I have just been looking at the xmlconcat bug on that list. I can't 
>> think of any better solution than parsing the resulting string to make 
>> sure it is well-formed before we return,
>>     
>
> That might be a reasonable thing to do as a safety check, but I can't
> escape the feeling that what this fundamentally is is a data typing
> error, traceable to the lack of differentiation between xml documents
> and xml fragments.  Is there a way to attack it based on saying that the
> inputs can't be documents, or stripping the document overhead if they are?
>   

Yeah, maybe. According to 
 the only 
legal child of an XML Document node that is not also a legal child of a 
DocumentFragment node is a DocumentType node. So we could probably just 
look for one of those in each argument node and strip it out. That 
should be fairly lightweight in the common case where it's not present - 
we'd just be searching for a fixed string. Removing it if found would be 
more complex. We'd have to parse the node to remove it, since a legal 
DocumentType node string could appear legally inside a CDATA node.

That has the advantage that it would fix the error rather than failing, 
but I'm slightly nervous about silently mangling user supplied XML. I 
guess we do that in a few other cases to make other combinations 
function sanely.

cheers

andrew


В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата:
От: Dimitri Fontaine
Дата:
FAQ