Re: [17] CREATE COLLATION default provider

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.

In response to

Responses

Browse pgsql-hackers by date

  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