Re: Bogus collation version recording in recordMultipleDependencies - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Bogus collation version recording in recordMultipleDependencies
Date
Msg-id 20210417092309.vdmqiidn4ddhyoew@nol
Whole thread Raw
In response to Re: Bogus collation version recording in recordMultipleDependencies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Apr 16, 2021 at 01:07:52PM -0400, Tom Lane wrote:
> I wrote:
> > ... or maybe not just yet.  Andres' buildfarm critters seem to have
> > a different opinion than my machine about what the output of
> > collate.icu.utf8 ought to be.  I wonder what the prevailing LANG
> > setting is for them, and which ICU version they're using.
> 
> Oh, I bet it's "C.utf8", because I can reproduce the failure with that.
> This crystallizes a nagging feeling I'd had that you were misdescribing
> the collate.icu.utf8 test as not being run under --no-locale.  Actually,
> it's only skipped if the encoding isn't UTF8, not the same thing.
> I think we need to remove the default-collation cases from that test too.

IIUC pg_regress --no-locale will call initdb --no-locale which force the locale
to C, and in that case pg_get_encoding_from_locale() does force SQL_ASCII as
encoding.  But yes I clearly didn't think at all that you could set the various
env variables to C.utf8 which can then run the collate.icu.utf8 or linux.utf8
:(



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: Truncate in synchronous logical replication failed
Next
From: Julien Rouhaud
Date:
Subject: Re: Bogus collation version recording in recordMultipleDependencies