Re: Order changes in PG16 since ICU introduction
От | Robert Haas |
---|---|
Тема | Re: Order changes in PG16 since ICU introduction |
Дата | |
Msg-id | CA+Tgmob-XgUgGrDx4sEMS3t0AQFgpm4KZgRuCd58bY+TsUO1tQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Order changes in PG16 since ICU introduction (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Order changes in PG16 since ICU introduction
|
Список | pgsql-hackers |
On Tue, Jun 6, 2023 at 3:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Joe Conway <mail@joeconway.com> writes: > > On 6/6/23 15:18, Jeff Davis wrote: > >> The locale "C" is a special case, documented as a non-locale. So, if > >> LOCALE/--locale apply to ICU, then either ICU needs to handle locale > >> "C" in the expected way (v8 patch series); or when we see locale "C" we > >> need to somehow change the provider into something that can handle it > >> (v6 patch series changes it to the "none" provider). > > > +1 to the latter approach > > Also +1, except that I find "none" a rather confusing choice of name. > There *is* a provider, it's just PG itself not either libc or ICU. > I thought Joe's suggestion of "internal" made more sense. Or perhaps "builtin" or "postgresql". I'm just thinking that "internal" as a type name kind of means "you shouldn't be touching this from SQL" and we don't want to give people the idea that the "C" locale isn't something you should use. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: