On 10/09/2021 01:37, Tom Lane wrote:
> 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.
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)).
Just like it makes sense to do give a debug-level warning about
encodings seen in locale -a output but not recognized by us at all
(pg_get_encoding_from_locale(localebuf, false) < 0).
Therefore I think your patch with duplicated error message is better
than what we have currently. I don't see how adding debug-level messages
about skipping frontend-only encodings would be of any significant use here.
Unless someone more experienced in locales' subtleties would like to
chime in.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
