Re: XML Issue with DTDs

On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> While looking into ways to implement a XMLSTRIP function which extracts the textual contents of an XML value and de-escapes them (i.e. > Solving this seems a bit messy, unfortunately. First, I think we need to have some XMLOPTION value which is a superset of all the others - otherwise, dump & restore won't work reliably. That means either allowing DTDs if XMLOPTION is CONTENT, or inventing a third XMLOPTION, say ANY.

Or we can just decide that it was a bug that this was ever allowed,
and if you upgrade to $FIXEDVERSION you'll need to sanitize your data.
This is roughly what we did with encoding checks.

> We then need to ensure that combining XML values yields something that is valid according to the most general XMLOPTION setting. That means either
>
> (1) Removing the DTD from all but the first argument to XMLCONCAT, and similarly all but the first value passed to XMLAGG
>
> or
>
> (2) Complaining if these values contain a DTD.
>
> or
>
> (3) Allowing multiple DTDs in a document if XMLOPTION is, say, ANY.
>
> I'm not in favour of (3), since clients are unlikely to be able to process such a value. (1) matches how we currently handle XML declarations (<?xml …?>), so I'm slightly in favour of that.

I don't like #3, mostly because I don't like XMLOPTION ANY in the
first place. Either #1 or #2 sounds OK.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company