Re: [PATCH] Add CANONICAL option to xmlserialize
От | Jim Jones |
---|---|
Тема | Re: [PATCH] Add CANONICAL option to xmlserialize |
Дата | |
Msg-id | 5ad89a63-44e4-0f4b-bbd9-5ff783518d09@uni-muenster.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Add CANONICAL option to xmlserialize (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: [PATCH] Add CANONICAL option to xmlserialize
|
Список | 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!
В списке pgsql-hackers по дате отправления: