From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, 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> |
Subject: | Re: Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c) |
Date: | 2023-09-08 21:24:00 |
Message-ID: | 7073610042fcf97e1bea2ce08b7e0214b5e11094.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2023-09-08 at 15:24 +0900, Michael Paquier wrote:
> 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);
+1, thank you.
> And when the provider is not known, we could use:
> + elog(ERROR, "unsupported collprovider (%s)", "pg_myfunc");
It's not that the provider is "not known" -- if locale is NULL, then
the provider is known to be COLLPROVIDER_LIBC. So perhaps we can
instead do something like:
char provider = locale ? locale->provider : COLLPROVIDER_LIBC;
and then always follow the first error format?
[ Aside: it might be nice to refactor so that we used a pointer to a
special static struct rather than NULL, which would cut down on these
kinds of special cases. I had considered doing that before and didn't
get around to it. ]
> @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?
Agreed.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Gabriele Bartolini | 2023-09-08 21:31:50 | Re: Possibility to disable `ALTER SYSTEM` |
Previous Message | Bruce Momjian | 2023-09-08 21:10:51 | Re: About #13489, array dimensions and CREATE TABLE ... LIKE |