Re: Collation versioning - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Collation versioning
Date
Msg-id CA+hUKGKa+22oiAsKcBTzxzsMtFw4MedjiBESO2nS2FndNaHjPA@mail.gmail.com
Whole thread Raw
In response to Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Mon, Nov 2, 2020 at 7:59 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> Note that v34 now fails when run on a without that don't have
> defined(__GLIBC__) (e.g. macos).  The failure are in
> collate.icu.utf8.sql, of the form:
>
> - icuidx06_d_en_fr_ga               | "default"  | up to date
> + icuidx06_d_en_fr_ga               | "default"  | version not tracked
>
> Given the new approach, the only option I can see is to simply remove
> any attempt to cover the default collation in the tests.  An
> alternative file would be a pain to maintain and it wouldn't bring any
> value apart from checking that the default collation is either always
> tracked or never, but not a mix of those.

Blah, right.  Ok, I changed it to output XXX for "default".

I did a bit more language clean up.  I fixed the tab completion for
ALTER INDEX ... ALTER COLLATION.  I simplified a couple of tests.  I
dropped the pg_dump TAP test for now (I might see if I can find a
simpler way to test refobjversion restoration later).  I dropped the
special handling for T_CollateExpr in find_expr_references_walker()
(it wasn't affecting the test cases we have, and I wasn't entirely
sure about it; do you see a problem?).  I dropped the VACUUM-log-spam
feature for now (I'm not against it, but it seems like an independent
enough thing to not include in the initial commit).  This brought the
patch mercifully under 100kB.  This is the version I'm planning to
commit if you don't see anything else.

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Parallel copy
Next
From: Masahiko Sawada
Date:
Subject: Fix a typo in verify_heapam.c