Re: Fix XML handling with DOCTYPE

From: Ryan Lambert <ryan(at)rustprooflabs(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>
Subject: Re: Fix XML handling with DOCTYPE
Date: 2019-03-27 01:39:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation: tested, passed

Overall I think this patch [1] improves the docs and help explain edge case functionality that many of us, myself included, don't fully understand. I can't verify technical accuracy for many of the details (nuances between XPath 1.0, et. al), but overall my experience with the XML functionality lines up with what has been documented here. Adding the clear declaration of "XPath 1.0" instead of the generic "XPath" helps make it clear of the functional differences and helps frame the differences for new users.

I have two recommendations for features.sgml. You state:

> relies on the libxml library

Should this be clarified as the libxml2 library? That's what I installed to build postgres from source (Ubuntu 16/18). If it is the libxml library and the "2" is irrelevant, or it it works with either, it might be nice to have a clarifying note to indicate that.

There are a few places where the parenthesis around a block of text seem unnecessary. I don't think parens serve a purpose when a full sentence is contained within.

> (The libxml library does seem to always return nodesets to PostgreSQL with their members in the same relative order they had in the input document; it does not commit to this behavior, and an XPath 1.0 expression cannot control it.)

It seems you are standardizing from "node set" to "nodeset", is that the preferred nomenclature or preference?

Hopefully this helps! Thanks,

Ryan Lambert


The new status of this patch is: Waiting on Author

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2019-03-27 02:35:03 RE: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Haribabu Kommi 2019-03-27 01:23:03 Re: Transaction commits VS Transaction commits (with parallel) VS query mean time