Re: Possible to create a hidden collation - Mailing list pgsql-bugs

From Jeff Davis
Subject Re: Possible to create a hidden collation
Date
Msg-id 0cecbce97966383dfa607f860249267d932b6921.camel@j-davis.com
Whole thread Raw
In response to Re: Possible to create a hidden collation  ("Daniel Verite" <daniel@manitou-mail.org>)
List 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




pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17933: pgAgent - password doesn't work
Next
From: Michael Paquier
Date:
Subject: Re: BUG #17731: Server doesn't start after abnormal shutdown while creating unlogged tables