On Thu, Feb 29, 2024 at 04:01:47AM +0100, Jelte Fennema-Nio wrote: > On Thu, 29 Feb 2024 at 01:57, Michael Paquier <mich...@paquier.xyz> wrote: >> I have doubts about the changes in raw_pg_bind_textdomain_codeset(), >> as the encoding could come from the value in the pg_database tuples >> themselves. The current coding is slightly safer from the perspective >> of bogus input values as we would loop over pg_enc2gettext_tbl looking >> for a match. 0003 changes that so as we could point to incorrect >> memory areas rather than fail safely for the NULL check. > > That's fair. Attached is a patch that adds a PG_VALID_ENCODING check > to raw_pg_bind_textdomain_codeset to solve this regression.
- for (i = 0; pg_enc2gettext_tbl[i].name != NULL; i++)
+ if (!PG_VALID_ENCODING(encoding) || pg_enc2gettext_tbl[encoding] == NULL)
{
Shouldn't PG_MULE_INTERNAL point to NULL in pg_enc2gettext_tbl[]?
That just seems safer to me, and more consistent because its values
satisfies PG_VALID_ENCODING().
--
Michael
signature.asc
Description: PGP signature
