From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [17] CREATE COLLATION default provider |
Date: | 2024-01-18 10:15:31 |
Message-ID: | 79893a79-ebc0-4898-bed8-4ee74fe93f90@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-01-18 10:49:18 | Re: minor replication slot docs edits |
Previous Message | Ashutosh Bapat | 2024-01-18 09:55:17 | Re: Report planning memory in EXPLAIN ANALYZE |