Re: [PATCH] Add CANONICAL option to xmlserialize

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Add CANONICAL option to xmlserialize
Date: 2023-03-05 22:20:19
Message-ID: 5ad89a63-44e4-0f4b-bbd9-5ff783518d09@uni-muenster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05.03.23 22:00, Thomas Munro wrote:
> The CI run for that failed in an interesting way, only on Debian +
> Meson, 32 bit. The diffs appear to show that psql has a different
> opinion of the column width, while building its header (the "------"
> you get at the top of psql's output), even though the actual column
> contents was the same. regression.diff[2] shows that there is a "£1"
> in the output, which is how UTF-8 "£1" looks if you view it with
> Latin1 glasses on. Clearly this patch involves transcoding, Latin1
> and UTF-8
One of the use cases of this patch is exactly the transcoding of a non
utf-8 document to utf-8 - as described in the XML canonical spec.
> and I haven't studied it, but it's pretty weird for the 32
> bit build to give a different result...
Yeah, it's pretty weird indeed. I'll try to reproduce this environment
in a container to see if I get the same diff. Although I'm not sure that
by "fixing" the result set for this environment it won't break all the
others.
> could be something to do with
> our environment, since .cirrus.yml sets LANG=C in the 32 bit test run
> -- maybe try that locally?
Also using LANGUAGE=C the result is the same for me - all tests pass
just fine.
> That run also generated a core dump, but I think that's just our open
> SIGQUIT problem[3] and not relevant here.
>
> [1] https://cirrus-ci.com/build/6319462375227392
> [2] https://api.cirrus-ci.com/v1/artifact/task/5800598633709568/testrun/build-32/testrun/regress/regress/regression.diffs
> [3] https://www.postgresql.org/message-id/flat/20230214202927.xgb2w6b7gnhq6tvv%40awork3.anarazel.de

Thanks for the quick reply. Much appreciated!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-03-05 22:20:48 Re: Refactor to introduce pg_strcoll().
Previous Message Joseph Koshakow 2023-03-05 21:14:48 Re: Date-Time dangling unit fix