On Sun, Aug 8, 2010 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
>>> I think the point of this function is to determine whether a cast to
>>> xml will throw an error. The behavior should probably match exactly
>>> whatever test would be applied there.
>
>> Maybe there should be
>
>> xml_is_well_formed()
>> xml_is_well_formed_document()
>> xml_is_well_formed_content()
>
>> I agree that consistency with SQL/XML is desirable, but for someone
>> coming from the outside, the unqualified claim that 'foo' is well-formed
>> XML might sound suspicious.
>
> I think I agree with the later discussion that xml_is_well_formed()
> should tell you whether a cast to xml would succeed (and hence it has to
> pay attention to XMLOPTION). However, it seems to also make sense to
> provide the other two functions suggested here, both to satify people
> who know XML and to offer tests that will tell you whether
> XMLPARSE ( { DOCUMENT | CONTENT } value ) will succeed.
>
> Merging the three cases into one function doesn't seem like a win
> for either compatibility or usability.
+1. I didn't realize how funky the XMLOPTION stuff was at the start
of this discussion; I think your analysis here is spot-on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company