On Sun, Aug 8, 2010 at 1:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers