From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Using the %m printf format more |
Date: | 2024-03-11 06:30:30 |
Message-ID: | Ze6lBpOSHMANU6fq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 06, 2024 at 07:11:19PM +0000, Dagfinn Ilmari Mannsåker wrote:
> I just noticed that commit d93627bc added a bunch of pg_fatal() calls
> using %s and strerror(errno), which could be written more concisely as
> %m. I'm assuming this was done because the surrounding code also uses
> this pattern, and hadn't been changed to use %m when support for that
> was added to snprintf.c to avoid backporting hazards. However, that
> support was in v12, which is now the oldest still-supported back branch,
> so we can safely make that change.
Right. This may still create some spurious conflicts, but that's
manageable for error strings. The changes in your patch look OK.
> The attached patch does so everywhere appropriate. One place where it's
> not appropriate is the TAP-emitting functions in pg_regress, since those
> call fprintf()
I am not really following your argument with pg_regress.c and
fprintf(). d6c55de1f99a should make that possible even in the case of
emit_tap_output_v(), no?
> and other potentially errno-modifying functions before
> evaluating the format string.
Sure.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-03-11 06:43:17 | Re: WIP Incremental JSON Parser |
Previous Message | Pavel Stehule | 2024-03-11 06:21:11 | Re: Schema variables - new implementation for Postgres 15 |