Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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
<http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html> 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