On 11/21/2017 11:49 AM, Tom Lane wrote: > AFAICS, XMLSERIALIZE in our current implementation boils down to > being a binary-compatible coercion from XML (which is stored as > a string) to text. So the interesting question here is where are > you getting the XML values from? The stability of the results is > going to be whatever the next level down does.
Well, constructed using xmlelement and xmlattributes in a big query. The structure of the query does not change from one run to the next. So as long as the internal XML form is essentially already serialized, I guess it comes down to what xmlattributes(...) inside xmlelement produces. If that is stable, say in the order of the attribute arguments, then that probably fits the bill. I don't see that clearly addressed in the doc for xmlattributes either. Should something be added to the docs, it's probably worth mentioning at XMLSERIALIZE anyway, keeping the fact that the internal form is already serialized as more of an implementation detail. -Chap select xmlserialize(document xmlroot( xmlelement(name top, xmlattributes( foo, bar, baz ), xmlelement(name things, ( select xmlagg( xmlelement(name thing, xmlattributes( name, importance, awesomeness, fluidity ), case when comment is not null then xmlelement(name comment, comment) end, ( select xmlagg( xmlelement(name property, xmlattributes(setting) ) ) from unnest(properties) as q(setting) ), ( select xmlagg( xmlelement(name referenced, xmlattributes( linksrc as source ) ) ) from ( select distinct ...