Re: review: xml_is_well_formed

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: review: xml_is_well_formed
Дата
Msg-id AANLkTikkWJCWSW0Z3EUi51Q+bG1ymgnrLaZQe_c9Hyix@mail.gmail.com
обсуждение исходный текст
Ответ на Re: review: xml_is_well_formed  (Mike Fowler <mike@mlfowler.com>)
Ответы Re: review: xml_is_well_formed  (Mike Fowler <mike@mlfowler.com>)
Re: review: xml_is_well_formed  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Fri, Aug 6, 2010 at 4:28 AM, Mike Fowler <mike@mlfowler.com> wrote:
> On 03/08/10 16:15, Peter Eisentraut wrote:
>>
>> On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
>>>>
>>>> Well-formedness should probably only allow XML documents.
>>>
>>> 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.
>
> What about making the function sensitive to the XML OPTION, such that:
>
> test=# SET xmloption TO DOCUMENT;
> SET
> text=# SELECT xml_is_well_formed('foo');
>
>  xml_is_well_formed
>  --------------------
>  f
>  (1 row)

That will make using this function a huge hassle, won't it?  Functions
that do different things depending on GUC settings are usually
troublesome.  Having three functions would be more sensible if we need
all three behaviors, but I don't see why we do.

Or perhaps it could return a string instead of a boolean: content,
document, or NULL if it's neither.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: MERGE Specification
Следующее
От: Fujii Masao
Дата:
Сообщение: default of max_stack_depth