review: xml_is_well_formed
in [PgSql]
|
Prev: ANALYZE versus expression indexes with nondefaultopckeytype
Next: [HACKERS] More fun with GIN lossy-page pointers
From: Mike Fowler on 6 Aug 2010 04:28 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) test=# SET xmloption TO CONTENT; SET text=# SELECT xml_is_well_formed('foo'); xml_is_well_formed -------------------- t (1 row) with the inverse for DOCUMENTS? To me this makes the most sense as it makes the function behave much more like the other xml functions. -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 6 Aug 2010 07:31 On Fri, Aug 6, 2010 at 4:28 AM, Mike Fowler <mike(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mike Fowler on 6 Aug 2010 09:43
On 06/08/10 12:31, Robert Haas wrote: >>> >>> 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. > I like the sound of that. In fact this helps workaround the IS DOCUMENT and IS CONTENT limitations such that you can you can select only content, only documents or both is you use IS NOT NULL. Unless anyone sees a reason that this function needs to remain a boolean function, I'll rework the patch over the weekend. Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |