From: | Anton Voloshin <a(dot)voloshin(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-10 06:47:48 |
Message-ID: | 0ad8d349-8857-bcb1-8dea-64a393017713@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-09-10 06:56:18 | Re: Add jsonlog log_destination for JSON server logs |
Previous Message | Noah Misch | 2021-09-10 06:39:18 | pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas |