Re: Improve readability by using designated initializers when possible

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Japin Li <japinli(at)hotmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Improve readability by using designated initializers when possible
Date: 2024-02-29 00:56:55
Message-ID: Zd_WV-JbrwoZj_Vn@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 28, 2024 at 05:37:22AM +0100, Jelte Fennema-Nio wrote:
> On Wed, 28 Feb 2024 at 04:59, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Cool. I have applied 0004 and most of 0002. Attached is what
>> remains, where I am wondering if it would be cleaner to do these bits
>> together (did not look at the whole, yet).
>
> Feel free to squash them if you prefer that. I think now that patch
> 0002 only includes encoding changes, I feel 50-50 about grouping them
> together. I mainly kept them separate, because 0002 were simple search
> + replaces and 0003 required code changes. That's still the case, but
> now I can also see the argument for grouping them together since that
> would clean up all the encoding arrays in one single commit (without a
> ton of other arrays also being modified).

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 not something that shows up as a problem for all the other
structures that have been changed afd8ef39094b or ef5e2e90859a.
That's not an issue for pg_enc2name_tbl, pg_enc2icu_tbl and
pg_wchar_table either thanks to PG_VALID(_{BE,FE})_ENCODING()
that offer protection with the index values used for the table
lookups.

- * WARNING: the order of this enum must be same as order of entries
- * in the pg_enc2name_tbl[] array (in src/common/encnames.c), and
- * in the pg_wchar_table[] array (in src/common/wchar.c)!
- *
- * If you add some encoding don't forget to check
+ * WARNING: If you add some encoding don't forget to check
* PG_ENCODING_BE_LAST macro.

Mentioning the updates to pg_enc2name_tbl[] and pg_wchar_table[] is
still important, IMO, because new encoding values added to the central
enum would cause the lookups of the tables to fail while passing the
PG_VALID checks, so updating them is mandatory and could be missed.
I've tweaked the comment to mention both of them; the order does not
matter anymore. Applied 0002 with these adjustments.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-02-29 01:24:20 Re: Improve eviction algorithm in ReorderBuffer
Previous Message Tatsuo Ishii 2024-02-29 00:19:54 Re: Row pattern recognition