From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c) |
Date: | 2023-09-08 06:24:28 |
Message-ID: | ZPq+HKWh8fQ05/5U@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 06, 2023 at 07:57:03AM -0300, Ranier Vilela wrote:
> I think no one objected.
Looking closer, there is much more inconsistency in this file
depending on the routine called. How about something like the v2
attached instead to provide more context in the error message about
the function called? Let's say, when the provider is known, we could
use:
+ elog(ERROR, "unsupported collprovider (%s): %c",
+ "pg_strncoll", locale->provider);
And when the provider is not known, we could use:
+ elog(ERROR, "unsupported collprovider (%s)", "pg_myfunc");
@Jeff (added now in CC), the refactoring done in d87d548c seems to be
at the origin of this confusion, because, before this commit, we never
generated this specific error for all these APIs where the locale is
undefined. What is your take here?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
pglocale-elogs-v2.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-09-08 06:29:41 | Re: Impact of checkpointer during pg_upgrade |
Previous Message | Amit Kapila | 2023-09-08 06:20:37 | Re: persist logical slots to disk during shutdown checkpoint |