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-09 18:37:52
Message-ID: 3723477.1631212672@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 09/09/2021 21:51, Tom Lane wrote:
>> Assuming we don't want to change pg_get_encoding_from_locale()'s API,
>> the simplest fix is to duplicate its error message, so more or less
>>
>> if (enc < 0)
>> {
>> - /* error message printed by pg_get_encoding_from_locale() */
>> + elog(DEBUG1, "could not determine encoding for locale \"%s\"",
>> + localebuf)));
>> continue;
>> }

> Upon thinking a little more, I agree.

Another approach we could take is to deem the comment incorrect and
just remove it, codifying the current behavior of silently ignoring
unrecognized encodings. The reason that seems like it might be
appropriate is that the logic immediately below this bit silently
ignores encodings that are known but are frontend-only:

if (!PG_VALID_BE_ENCODING(enc))
continue; /* ignore locales for client-only encodings */

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-09-09 18:49:34 Re: [Patch] ALTER SYSTEM READ ONLY
Previous Message Jaime Casanova 2021-09-09 18:26:00 Re: Feedback on table expansion hook (including patch)