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
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 |