Re: review: xml_is_well_formed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Mike Fowler <mike(at)mlfowler(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: xml_is_well_formed
Date: 2010-08-08 17:45:20
Message-ID: 6299.1281289520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On lr, 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-08-08 18:01:48 Re: review: psql: edit function, show function commands patch
Previous Message David E. Wheeler 2010-08-08 17:33:33 Re: Initial review of xslt with no limits patch