Re: review: xml_is_well_formed - Mailing list pgsql-hackers

From Robert Haas
Subject Re: review: xml_is_well_formed
Date
Msg-id AANLkTi=my3mfdghX2pK2JM_1fj+1SNsJJpgz3N-bJ6mY@mail.gmail.com
Whole thread Raw
In response to Re: review: xml_is_well_formed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: ALTER TYPE extensions
Next
From: Mark Wong
Date:
Subject: parallel quicksort