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-03-01 04:12:35 |
Message-ID: | ZeFVsxNLwiLaOhlY@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2024-03-01 04:15:05 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | Michael Paquier | 2024-03-01 04:08:15 | Re: Improve readability by using designated initializers when possible |