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
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 |