Re: Collation versioning

On Wed, 4 Nov 2020 at 14:21, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Wed, Nov 4, 2020 at 10:56 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Wed, Nov 4, 2020 at 10:52 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > > > We want the same algorithm that Windows uses internally to resolve the
> > > > old style name to a collation; in other words we probably want
> > > > something more like the code path that they took away in VS2015 :-(.
> > >
> > > Yeah. In the short run, though, it'd be nice to un-break the buildfarm.
> > > Maybe we could push David's code or something similar, and then
> > > contemplate better ways at leisure?
> >
> > Ok, yeah, I'll do that in the next few hours.
>
> I can't bring myself to commit that, it's not really in the spirit of
> this data integrity feature, and it's not our business to second guess
> the relationship between different locale naming schemes through fuzzy
> logic. Instead, I propose to just neuter the feature if Windows
> decides it can't understand a locale names that it gave us. It should
> still work fine with something like initdb --lc-collate=en-US. Here's
> an untested patch. Thoughts?

I gave this a quick test.

initdb works fine. I ran vcregress upgradecheck and it passes.

With my default locale of English.New Zealand.1252 I get zero rows from:

select * from pg_depend where coalesce(refobjversion,'') <> '';

if I initdb with --lc-collate=en-NZ, it works and I see:

postgres=# select * from pg_depend where coalesce(refobjversion,'') <> '';
classid | objid | objsubid | refclassid | refobjid | refobjsubid |
deptype | refobjversion
---------+-------+----------+------------+----------+-------------+---------+-----------------
2606 | 12512 | 0 | 3456 | 100 | 0 | n
| 1538.14,1538.14
(1 row)

David