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
