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(namereferenced, xmlattributes( linksrc as source )
) ) from ( select distinct
...
