Horton

Re: Improve readability by using designated initializers when possible

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Japin Li <japinli@hotmail.com>, jian he <jian.universality@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers@lists.postgresql.org
Date: 2024-03-01T04:12:35Z
Lists: pgsql-hackers 
On Thu, Feb 29, 2024 at 04:01:47AM +0100, Jelte Fennema-Nio wrote:
> On Thu, 29 Feb 2024 at 01:57, Michael Paquier <michael@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

Commits

  1. Remove ObjectClass type

  2. Simplify pg_enc2gettext_tbl[] with C99-designated initializer syntax

  3. Use C99-designated initializer syntax for arrays related to encodings

  4. Remove last NULL element in config_group_names[]

  5. Use C99-designated initializer syntax for more arrays

  6. Remove unnecessary array object_classes[] in dependency.c

  7. Add trailing commas to enum definitions