Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clean up error messages from 1495eff7bdb

  1. Unquoted file name in an error message

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2025-04-07T06:27:21Z

    Hello.

While translating error messages related to pg_dumpall (1495eff7bdb),
I noticed that one message lacks double quotes around the file name:

  could not open map file: %s

Since this placeholder appears standalone and not embedded in a
sentence, I initially thought it might fall outside the usual
convention of quoting file names. However, a similar message added to
pg_restore does quote the file name, as in:

  could not open global.dat file: "%s"

So I believe this omission is unintentional.

The first of the attached patches adds double quotes around the file
name for consistency.

In addition, I noticed that pg_dump and pg_restore refer to map.dat
using different wording.  The second patch updates the message to
refer to "map.dat file" instead of "map file", for consistency with
how pg_restore refers to both "global.dat file" and "map.dat file"
explicitly.


I noticed that there are other messages in other files that refer to
file names without quotes as well, but I'm not addressing those here.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  2. Re: Unquoted file name in an error message

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-04-07T10:13:03Z

    On 2025-Apr-07, Kyotaro Horiguchi wrote:

> Hello.
> 
> While translating error messages related to pg_dumpall (1495eff7bdb),
> I noticed that one message lacks double quotes around the file name:
> 
>   could not open map file: %s
> 
> Since this placeholder appears standalone and not embedded in a
> sentence, I initially thought it might fall outside the usual
> convention of quoting file names.

Hello, I think the problem here is that the %s is not the file name, but
the string from strerror.  So the lack of quotes there would seem to be
correct.  The real problem is that the file name isn't mentioned in the
error message.  A secondary issue might be that instead of using %s for
strerror(), maybe they should be using %m.


> +			pg_fatal("could not open global.dat file: \"%s\"", strerror(errno));

Maybe we should do something like

		pg_fatal("could not open "%s" file: %m", map_file_path);

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

  3. Re: Unquoted file name in an error message

    Andrew Dunstan <andrew@dunslane.net> — 2025-04-07T13:10:12Z

    On 2025-04-07 Mo 6:13 AM, Álvaro Herrera wrote:
> On 2025-Apr-07, Kyotaro Horiguchi wrote:
>
>> Hello.
>>
>> While translating error messages related to pg_dumpall (1495eff7bdb),
>> I noticed that one message lacks double quotes around the file name:
>>
>>    could not open map file: %s
>>
>> Since this placeholder appears standalone and not embedded in a
>> sentence, I initially thought it might fall outside the usual
>> convention of quoting file names.
> Hello, I think the problem here is that the %s is not the file name, but
> the string from strerror.  So the lack of quotes there would seem to be
> correct.  The real problem is that the file name isn't mentioned in the
> error message.  A secondary issue might be that instead of using %s for
> strerror(), maybe they should be using %m.
>
>
>> +			pg_fatal("could not open global.dat file: \"%s\"", strerror(errno));
> Maybe we should do something like
>
> 		pg_fatal("could not open "%s" file: %m", map_file_path);
>


Yeah. Here's a more thorough error message cleanup.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com