Re: missing warning in pg_import_system_collations - Mailing list pgsql-hackers

Anton Voloshin <a.voloshin@postgrespro.ru> writes:
> On 10/09/2021 01:37, Tom Lane wrote:
>> It's sure not very clear to me why one case deserves a message and the
>> other not.  Perhaps they both do, which would lead to adding another
>> DEBUG1 message here.

> I'm not an expert in locales, but I think it makes some sense to be
> silent about encodings we have consciously decided to ignore as we have
> them in our tables, but marked them as frontend-only
> (!PG_VALID_BE_ENCODING(enc)).

I'm not really buying that.  It seems to me that the only reason anyone
would examine this debug output at all is that they want to know "why
didn't this locale (which I can see in 'locale -a' output) get imported?".
So the only cases I'm inclined to not log about are when we skip a locale
because there's already a matching pg_collation entry.

I experimented with the attached draft patch.  The debug output on my
RHEL8 box (with a more-or-less-default set of locales) looks like

2021-09-11 12:13:09.908 EDT [41731] DEBUG:  could not identify encoding for locale "hy_AM.armscii8"
2021-09-11 12:13:09.909 EDT [41731] DEBUG:  could not identify encoding for locale "ka_GE"
2021-09-11 12:13:09.909 EDT [41731] DEBUG:  could not identify encoding for locale "ka_GE.georgianps"
2021-09-11 12:13:09.909 EDT [41731] DEBUG:  could not identify encoding for locale "kk_KZ"
2021-09-11 12:13:09.909 EDT [41731] DEBUG:  could not identify encoding for locale "kk_KZ.pt154"
2021-09-11 12:13:09.926 EDT [41731] DEBUG:  could not identify encoding for locale "tg_TJ"
2021-09-11 12:13:09.926 EDT [41731] DEBUG:  could not identify encoding for locale "tg_TJ.koi8t"
2021-09-11 12:13:09.926 EDT [41731] DEBUG:  could not identify encoding for locale "th_TH"
2021-09-11 12:13:09.926 EDT [41731] DEBUG:  could not identify encoding for locale "th_TH.tis620"
2021-09-11 12:13:09.926 EDT [41731] DEBUG:  could not identify encoding for locale "thai"
2021-09-11 12:13:09.929 EDT [41731] DEBUG:  skipping client-only locale "zh_CN.gb18030"
2021-09-11 12:13:09.929 EDT [41731] DEBUG:  skipping client-only locale "zh_CN.gbk"
2021-09-11 12:13:09.930 EDT [41731] DEBUG:  skipping client-only locale "zh_HK"
2021-09-11 12:13:09.930 EDT [41731] DEBUG:  skipping client-only locale "zh_HK.big5hkscs"
2021-09-11 12:13:09.930 EDT [41731] DEBUG:  skipping client-only locale "zh_SG.gbk"
2021-09-11 12:13:09.930 EDT [41731] DEBUG:  skipping client-only locale "zh_TW"
2021-09-11 12:13:09.930 EDT [41731] DEBUG:  skipping client-only locale "zh_TW.big5"

I don't see a good reason to think that someone would be less confused
about why we reject zh_HK than why we reject th_TH.  So I think if we're
going to worry about this then we should add both messages.

            regards, tom lane

diff --git a/src/backend/commands/collationcmds.c b/src/backend/commands/collationcmds.c
index 4075f991a0..8fe8227751 100644
--- a/src/backend/commands/collationcmds.c
+++ b/src/backend/commands/collationcmds.c
@@ -597,11 +597,15 @@ pg_import_system_collations(PG_FUNCTION_ARGS)
             enc = pg_get_encoding_from_locale(localebuf, false);
             if (enc < 0)
             {
-                /* error message printed by pg_get_encoding_from_locale() */
+                elog(DEBUG1, "could not identify encoding for locale \"%s\"",
+                     localebuf);
                 continue;
             }
             if (!PG_VALID_BE_ENCODING(enc))
-                continue;        /* ignore locales for client-only encodings */
+            {
+                elog(DEBUG1, "skipping client-only locale \"%s\"", localebuf);
+                continue;
+            }
             if (enc == PG_SQL_ASCII)
                 continue;        /* C/POSIX are already in the catalog */