|From:||Chapman Flack <chap(at)anastigmatix(dot)net>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Ryan Lambert <ryan(at)rustprooflabs(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Fix XML handling with DOCTYPE|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 03/27/19 19:07, Chapman Flack wrote:
> xml-functions-type-docfix-5.patch attached, with node-sets instead of
> nodesets, libxml2 instead of libxml, and parenthesized full sentences
> now au naturel.
> I ended up turning the formerly-parenthesized note about libxml2's
> node-set ordering into a DocBook <note>: there is really something
> parenthetical about it, with the official statement of node-set
> element ordering being that there is none, and the description of
> what the library happens to do being of possible interest, but set
> apart, with the necessary caveats about relying on it.
I have just suffered a giant sinking feeling upon re-reading this
sentence in our XMLTABLE doc:
A column marked FOR ORDINALITY will be populated with row numbers
matching the order in which the output rows appeared in the original
input XML document.
I've been skimming right over it all this time, and that right there is
a glaring built-in reliance on the observable-but-disclaimed iteration
order of a libxml2 node-set.
I'm a bit unsure what any clarifying language should even say.
|Next Message||David Rowley||2019-03-27 23:36:24||Re: Berserk Autovacuum (let's save next Mandrill)|
|Previous Message||Chapman Flack||2019-03-27 23:07:43||Re: Fix XML handling with DOCTYPE|