Re: [17] CREATE COLLATION default provider

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [17] CREATE COLLATION default provider
Дата
Msg-id 79893a79-ebc0-4898-bed8-4ee74fe93f90@eisentraut.org
обсуждение исходный текст
Ответ на [17] CREATE COLLATION default provider  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: [17] CREATE COLLATION default provider  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On 15.06.23 06:47, Jeff Davis wrote:
> Currently, CREATE COLLATION always defaults the provider to libc.
> 
> The attached patch causes it to default to libc if LC_COLLATE/LC_CTYPE
> are specified, otherwise default to the current database default
> collation's provider.
> 
> That way, the provider choice at initdb time then becomes the default
> for "CREATE DATABASE ... TEMPLATE template0", which then becomes the
> default provider for "CREATE COLLATION (LOCALE='...')".

I like the general idea.  If the user has selected ICU overall, it could 
be sensible that certain commands default to ICU.

I wonder, however, how useful this would be in practice.  In most 
interesting cases, you need to know what the provider is to be able to 
spell out the locale name appropriately.  The cases where some overlap 
exists, like the common "ll_CC", are already preloaded, so won't 
actually need to be specified explicitly in many cases.

Also, I think the default should only flow one way, top-down:  The 
default provider of CREATE COLLATION is datlocprovider.  There shouldn't 
be a second, botton-up way, based on the other specified CREATE 
COLLATION parameters.  That's just too much logical zig-zag, IMO. 
Otherwise, if you extend this locally, why not also look at if 
"deterministic" or "rules" was specified, etc.



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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Report planning memory in EXPLAIN ANALYZE
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: minor replication slot docs edits