Re: Collation version tracking for macOS

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Collation version tracking for macOS
Дата
Msg-id CA+hUKGJhPeW3iRqO3XQB=+BTMx7O6zTCFKTfeSV9TXBtdyMqbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation version tracking for macOS  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Collation version tracking for macOS  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Thu, Nov 24, 2022 at 3:07 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I'd vote for 1 on the grounds that it's easier to document and
> understand a single collation version, which comes straight from
> ucol_getVersion(). This approach makes it a separate problem to find
> the collation version among whatever libraries the admin can provide;
> but adding some observability into the search should mitigate any
> confusion.

OK, it sounds like I should code that up next.

> Can you go over the advantages of approaches 2-4 again? Is it just a
> concern about burdening the admin with finding the right ICU library
> version for a given collation version? That's a valid concern, but I
> don't think that should be an overriding design point. It seems more
> important to model the collation versions properly.

Yes, that's a good summary.  The user has a problem, and the solution
is to find some version of ICU and install it, so the problem space
necessarily involves the other kind of version.  My idea was that we
should therefore make that part of the model.  But the observability
support does indeed make it a bit clearer what's going on.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Hash index build performance tweak from sorting
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Allow file inclusion in pg_hba and pg_ident files