From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Possible to create a hidden collation |
Date: | 2023-05-15 22:04:21 |
Message-ID: | 0cecbce97966383dfa607f860249267d932b6921.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, 2023-05-13 at 14:28 +0200, Daniel Verite wrote:
> ISTM that this behavior is not due to collencoding=-1, but
> to the custom "en_US" collation being in the "public" schema
> whereas the built-in "en_US" is in "pg_catalog".
My mistake -- it looks like this is not a bug and I don't see a real
problem here. Thank you for looking.
> So maybe it's better to set collencoding to the db encoding as done
> by the patch, but it's not clear what concrete problem it solves.
I was a bit bothered by the inconsistency between libc and icu here,
and I still feel like this patch is probably the right thing to do.
If nothing else, right now the error messages are inconsistent:
create collation test(provider='libc', locale='en_US.utf8');
CREATE COLLATION
create collation test(provider='libc', locale='en_US.utf8');
ERROR: collation "test" for encoding "UTF8" already exists
create collation test(provider='icu', locale='und');
ERROR: collation "test" already exists
The patch fixes that. Not terribly important, but having a consistent
catalog representation seems like a good idea.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-05-15 23:45:45 | Re: BUG #17731: Server doesn't start after abnormal shutdown while creating unlogged tables |
Previous Message | PG Bug reporting form | 2023-05-15 12:33:13 | BUG #17933: pgAgent - password doesn't work |