Re: Fix XML handling with DOCTYPE
От | Ryan Lambert |
---|---|
Тема | Re: Fix XML handling with DOCTYPE |
Дата | |
Msg-id | CAN-V+g-WQtQkn7EEDAZLP_4ho4fbcMGcssooVLS=PNhDwgRF_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix XML handling with DOCTYPE (Chapman Flack <chap@anastigmatix.net>) |
Список | pgsql-hackers |
I applied and reviewed xml-functions-type-docfix-6.patch. Looks good to me.
I like the standardization (e.g. libxml2, node-set) and I didn't catch any spots that used the other versions. I agree that the <note> is appropriate for that block.
It also looks like you incorporated Alvaro's feedback about sorting, or the lack thereof.
Let me know if there's anything else I can do to help get this accepted. Thanks,
Ryan
On Thu, Mar 28, 2019 at 5:45 PM Chapman Flack <chap@anastigmatix.net> wrote:
On 03/27/19 19:27, Chapman Flack wrote:
> 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.
So, xml-functions-type-docfix-6.patch.
I changed that language to say "populated with row numbers, starting
with 1, in the order of nodes retrieved from the row_expression's
result node-set."
That's not such a terrible thing to have to say; in fact, it's the
*correct* description for the standard, XQuery-based, XMLTABLE (where
the language gives you control of the result sequence's order).
I followed that with a short note saying since XPath 1.0 doesn't
specify that order, relying on it is implementation-dependent, and
linked to the existing Appendix D discussion.
I would have like to link directly to the <listitem>, but of course
<xref> doesn't know what to call that, so I linked to the <sect3>
instead.
Regards,
-Chap
В списке pgsql-hackers по дате отправления: