Re: Fix XML handling with DOCTYPE

From: Ryan Lambert <ryan(at)rustprooflabs(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(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
Date: 2019-03-30 16:06:18
Message-ID: CAN-V+g-WQtQkn7EEDAZLP_4ho4fbcMGcssooVLS=PNhDwgRF_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anastigmatix(dot)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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-03-30 16:06:26 Re: speeding up planning with partitions
Previous Message Robert Haas 2019-03-30 15:59:32 Re: speeding up planning with partitions