Re: [PATCH] Add CANONICAL option to xmlserialize - Mailing list pgsql-hackers

From Jim Jones
Subject Re: [PATCH] Add CANONICAL option to xmlserialize
Date
Msg-id 3b0b381b-a89f-4bb1-a1d3-25b2ba7b8907@uni-muenster.de
Whole thread
In response to Re: [PATCH] Add CANONICAL option to xmlserialize  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: [PATCH] Add CANONICAL option to xmlserialize
List pgsql-hackers
On 30/03/2026 13:27, Jim Jones wrote:
> On 30/03/2026 11:44, Andrew Dunstan wrote:
>> I note that your function returns xml, whereas Tom's suggestion was for
>> a function returning text. I don't think there was any discussion on the
>> point.
> Indeed, there was no discussion regarding the return type.
> 
> My rationale for keeping it as xml was: the output is xml, callers can
> immediately use the xml without casting, and nearly all other xml*
> functions return xml. Is there a direct advantage of having this
> function return text?


After some consideration, I think returning text instead of xml is
indeed the better choice here. The canonical form is a serialization
artifact rather than a document intended for further XML processing.
More practically, since xml has no = operator, the primary use case of
comparing documents requires casting anyway -- returning text is indeed
closer to real-world usage.

I also noticed a correctness issue with database encoding: the C14N 1.1
specification mandates UTF8 output, so xmlC14NDocDumpMemory always
returns UTF8.[1] I added a pg_any_to_server call to convert the output
to the server encoding before returning.

Best, Jim

1 -
https://github.com/GNOME/libxml2/blob/174201f747da93167354287a7599d0b385552599/c14n.c#L1964

Attachment

pgsql-hackers by date:

Previous
From: Imran Zaheer
Date:
Subject: Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)
Next
From: Andriy Dorokhin
Date:
Subject: RFC: Boyer-Moore-Horspool optimization for LIKE '%pattern%' searches