Re: missing warning in pg_import_system_collations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Anton Voloshin <a(dot)voloshin(at)postgrespro(dot)ru>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: missing warning in pg_import_system_collations
Date: 2021-09-11 16:19:49
Message-ID: 63920.1631377189@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anton Voloshin <a(dot)voloshin(at)postgrespro(dot)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

Attachment Content-Type Size
log-debug-messages-for-rejected-locales.patch text/x-diff 814 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-09-11 17:37:47 Re: Increase value of OUTER_VAR
Previous Message Andrey Borodin 2021-09-11 12:31:37 Compressing temporary files