rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Disallow creating an ICU collation if the DB encoding won't support it. 

Previously this was allowed, but the collation effectively vanished
into the ether because of the way lookup_collation() works: you could
not use the collation, nor even drop it.  Seems better to give an
error up front than to leave the user wondering why it doesn't work.

(Because this test is in DefineCollation not CreateCollation, it does
not prevent pg_import_system_collations from creating ICU collations,
regardless of the initially-chosen encoding.)

Per bug #17170 from Andrew Bille.  Back-patch to v10 where ICU support
was added.

Discussion: https://postgr.es/m/17170-95845cf3f0a9c36d@postgresql.org
This commit is contained in:
Tom Lane 2021-09-03 16:38:55 -04:00
parent 0c6a6a0ab7
commit db2760a841
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
src/backend/commands/collationcmds.c
View File

@ -215,7 +215,26 @@ DefineCollation(ParseState *pstate, List *names, List *parameters, bool if_not_e
if (!fromEl)
{
if (collprovider == COLLPROVIDER_ICU)
{
#ifdef USE_ICU
/*
* We could create ICU collations with collencoding == database
* encoding, but it seems better to use -1 so that it matches the
* way initdb would create ICU collations. However, only allow
* one to be created when the current database's encoding is
* supported. Otherwise the collation is useless, plus we get
* surprising behaviors like not being able to drop the collation.
*
* Skip this test when !USE_ICU, because the error we want to
* throw for that isn't thrown till later.
*/
if (!is_encoding_supported_by_icu(GetDatabaseEncoding()))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("current database's encoding is not supported with this provider")));
#endif
collencoding = -1;
}
else
{
collencoding = GetDatabaseEncoding();