Rui Zhao <[email protected]> writes:
>> Hmm, 0001 seems quite odd to me. Why bother to install a value for
>> doc->encoding at all, if we're not going to do so until after all
>> the calls that will pay attention to it? I tried simply commenting
>> out the assignment:
>> ...
>> and that seemed to work fine.
> After your suggestion, I traced later uses of doc->encoding and asked
> AI again to help construct a case. I verified it in PG with libxml2
> 2.9.7 and 2.12.5, in a UTF8 database:
> SELECT xmlserialize(CONTENT '<a value="é"/>' AS text INDENT);
> -- Master: <a value="é"/>
> -- With 0001: <a value="é"/>
> -- With #ifdef NOT_USED: <a value="é"/>
Interesting! I had tried substantially the same test, but using
"ñ" as a body-text character, and that case seems to get output
as a hex reference no matter what. It didn't occur to me that
characters inside tag attributes might get treated differently.
So I'll use 0001 as you have it, but I think while I'm at it
I will add test coverage for these behaviors.
> Agreed. The workaround could introduce other differences in library
> versions. I'm happy to leave this INDENT whitespace behavior to libxml2
> and drop 0002.
We're on the same page then. Thanks again for the review!
regards, tom lane
