Thread

Commits

  1. Fix grammar in short description of effective_wal_level.

  2. Simplify some log messages in extended_stats_funcs.c

  1. Miscellaneous message fixes

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-02-10T05:37:52Z

    Hello.
    
    I noticed that some error messages have issues such as non-standard
    wording, slightly odd output, and minor grammatical mistakes, and have
    attached patches addressing each of the items below.
    
    0001:
    guc_table.c:
    >		.name = "effective_wal_level",
    >...
    >		.short_desc = gettext_noop("Show effective WAL level."),
    
    We use "shows" in that context.
    
    
    0002:
    partbounds.c:
    > errhint("ALTER TABLE ... MERGE PARTITIONS requires the partition bounds to be adjacent."),
    ...
    > errhint("ALTER TABLE ... SPLIT PARTITION requires the partition bounds to be adjacent."),
    
    These messages share the same body only differ in the command name. On
    the other hand we have the following message in the same file.
    
    > errhint("%s require combined bounds of new partitions must exactly match the bound of the split partition",
    >					"ALTER TABLE ... SPLIT PARTITION"),
    
    So, I think that the first two messages shoud use the same structure
    with the last one.
    
    
    0003:
    
    The last message above mistakenly uses the present tense, and some
    other messages do the same. I think this should be fixed.
    
    
    0004:
    
    In the messages mentioned in 0002, the sentence structure is somewhat
    hard to parse. Adding “that” after “requires” should improve clarity,
    as in several other messages with the same issue.
    
    
    0005:
    
    In wait.c, there are three error messages with inconsistent wording:
    two use "timeout value", while one uses "timeout" to refer to the same
    object. This makes translation slightly awkward, so I suggest unifying
    the wording.
    
    
    0006: 
    In extended_stats_funcs.c:
    > errmsg("could not find extended statistics object \"%s\".\"%s\"",
    >        quote_identifier(nspname),
    >        quote_identifier(stxname)));
    
    Since quote_identifier() already adds quoting when needed, adding
    "%s"."%s" in the format string results in double quoting. It would be
    better to use %s.%s instead.  I think quoting should be applied only
    when necessary here. I'm not sure we should use
    quote_qualified_identifier() instead.. (It's not used in the attached
    patch).
    
    There's a similar inconsistency.
    
    >	errmsg("could not clear extended statistics object \"%s\".\"%s\": incorrect relation \"%s\".\"%s\" specified",
    >		   get_namespace_name(nspoid), stxname,
    >		   relnspname, relname));
    
    In this part, the names are not passed through quote_identifier().  It
    would be better to unify this as well.
    
    regards.
    
    -- 
    Kyotaro Horiguchi
    NTT Open Source Software Center
    
  2. Re: Miscellaneous message fixes

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-02-10T06:18:53Z

    At Tue, 10 Feb 2026 14:37:52 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
    > Hello.
    > 
    > I noticed that some error messages have issues such as non-standard
    > wording, slightly odd output, and minor grammatical mistakes, and have
    > attached patches addressing each of the items below.
    
    Oops, sorry, the patch set causes a test failure.
    I’ll look into it.
    
    regards.
    
    -- 
    Kyotaro Horiguchi
    NTT Open Source Software Center
    
  3. Re: Miscellaneous message fixes

    Michael Paquier <michael@paquier.xyz> — 2026-02-10T07:14:17Z

    On Tue, Feb 10, 2026 at 02:37:52PM +0900, Kyotaro Horiguchi wrote:
    > 0006: 
    > In extended_stats_funcs.c:
    >> errmsg("could not find extended statistics object \"%s\".\"%s\"",
    >>        quote_identifier(nspname),
    >>        quote_identifier(stxname)));
    > 
    > Since quote_identifier() already adds quoting when needed, adding
    > "%s"."%s" in the format string results in double quoting. It would be
    > better to use %s.%s instead.  I think quoting should be applied only
    > when necessary here. I'm not sure we should use
    > quote_qualified_identifier() instead.. (It's not used in the attached
    > patch).
    > 
    > There's a similar inconsistency.
    > 
    >>	errmsg("could not clear extended statistics object \"%s\".\"%s\": incorrect relation \"%s\".\"%s\" specified",
    >>		   get_namespace_name(nspoid), stxname,
    >>		   relnspname, relname));
    > 
    > In this part, the names are not passed through quote_identifier().  It
    > would be better to unify this as well.
    
    0006 relates to some of my recent business, so I'll go look and
    address this part.  Thanks for the report. 
    --
    Michael
    
  4. Re: Miscellaneous message fixes

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-02-10T10:26:55Z

    On 2026-Feb-10, Kyotaro Horiguchi wrote:
    
    Hello,
    
    > 0006: 
    > In extended_stats_funcs.c:
    > > errmsg("could not find extended statistics object \"%s\".\"%s\"",
    > >        quote_identifier(nspname),
    > >        quote_identifier(stxname)));
    > 
    > Since quote_identifier() already adds quoting when needed, adding
    > "%s"."%s" in the format string results in double quoting. It would be
    > better to use %s.%s instead.  I think quoting should be applied only
    > when necessary here. I'm not sure we should use
    > quote_qualified_identifier() instead.. (It's not used in the attached
    > patch).
    > 
    > There's a similar inconsistency.
    > 
    > >	errmsg("could not clear extended statistics object \"%s\".\"%s\": incorrect relation \"%s\".\"%s\" specified",
    > >		   get_namespace_name(nspoid), stxname,
    > >		   relnspname, relname));
    > 
    > In this part, the names are not passed through quote_identifier().  It
    > would be better to unify this as well.
    
    Hmm, in the vast majority of messages, the quotes are in the literal
    string, and we do not add quote_identifier().  This way, the names are
    always quoted, not just when they are funny identifiers; also the
    translator chooses the quoting style they want, which is not necessarily
    the same as the one used in English.
    
    So my recommendation would be to remove the quote_identifier() calls and
    leave the quotes in the message.
    
    -- 
    Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
    
    
    
    
  5. Re: Miscellaneous message fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-10T14:55:23Z

    =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
    > On 2026-Feb-10, Kyotaro Horiguchi wrote:
    >> In extended_stats_funcs.c:
    >>> errmsg("could not find extended statistics object \"%s\".\"%s\"",
    >>>        quote_identifier(nspname),
    >>>        quote_identifier(stxname)));
    >> 
    >> Since quote_identifier() already adds quoting when needed, adding
    >> "%s"."%s" in the format string results in double quoting. It would be
    >> better to use %s.%s instead.  I think quoting should be applied only
    >> when necessary here. I'm not sure we should use
    >> quote_qualified_identifier() instead.
    
    > Hmm, in the vast majority of messages, the quotes are in the literal
    > string, and we do not add quote_identifier().  This way, the names are
    > always quoted, not just when they are funny identifiers; also the
    > translator chooses the quoting style they want, which is not necessarily
    > the same as the one used in English.
    
    Yeah, this code is simply wrong.  You should remove the
    quote_identifier() calls and otherwise leave it as-is.
    
    quote_identifier(), quote_qualified_identifier(), etc are meant for
    building valid SQL strings.  However, an error message is a totally
    different animal.  We decided years ago that the preferred style is
    to wrap "..." around the unadorned identifier *in the error text*,
    not by using quote_identifier(), so that translators could replace
    the double-quote marks with appropriate marks for their language.
    Is the English version 100% consistent in the presence of identifiers
    containing double-quote marks?  No.  But we'd be making matters
    worse not better for other languages if we did it differently.
    
    This choice is documented at
    
    https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-QUOTATION-MARKS
    
    			regards, tom lane
    
    
    
    
  6. Re: Miscellaneous message fixes

    Michael Paquier <michael@paquier.xyz> — 2026-02-10T22:03:47Z

    On Tue, Feb 10, 2026 at 09:55:23AM -0500, Tom Lane wrote:
    > Yeah, this code is simply wrong.  You should remove the
    > quote_identifier() calls and otherwise leave it as-is.
    > 
    > quote_identifier(), quote_qualified_identifier(), etc are meant for
    > building valid SQL strings.  However, an error message is a totally
    > different animal.  We decided years ago that the preferred style is
    > to wrap "..." around the unadorned identifier *in the error text*,
    > not by using quote_identifier(), so that translators could replace
    > the double-quote marks with appropriate marks for their language.
    > Is the English version 100% consistent in the presence of identifiers
    > containing double-quote marks?  No.  But we'd be making matters
    > worse not better for other languages if we did it differently.
    
    Right, I had a brain fart on this one.  Using "%s"."%s" where the
    namespace and object names were independently quoted is also not
    project style.  At the end, I have removed the quote_identifier()
    calls altogether, and reduced the number of quotes in the error
    strings, leading to f33c58577422 as a result.  If there is anything
    else, please let me know. 
    --
    Michael
    
  7. Re: Miscellaneous message fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-10T22:17:13Z

    Michael Paquier <michael@paquier.xyz> writes:
    > Right, I had a brain fart on this one.  Using "%s"."%s" where the
    > namespace and object names were independently quoted is also not
    > project style.  At the end, I have removed the quote_identifier()
    > calls altogether, and reduced the number of quotes in the error
    > strings, leading to f33c58577422 as a result.  If there is anything
    > else, please let me know. 
    
    Yeah, f33c58577422 looks like what we've done elsewhere.  OK by me.
    
    			regards, tom lane
    
    
    
    
  8. Re:Miscellaneous message fixes

    zengman <zengman@halodbtech.com> — 2026-02-11T10:28:44Z

    Hi,
    
    Per (https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-TRICKY-WORDS) where it says: 
    ```
    Avoid contractions, like “can't”; use “cannot” instead.
    ```
    could we add an extra 0007 patch for this?
    
    --
    regards,
    Man Zeng
  9. Re: Miscellaneous message fixes

    Michael Paquier <michael@paquier.xyz> — 2026-03-10T06:05:04Z

    On Tue, Feb 10, 2026 at 02:37:52PM +0900, Kyotaro Horiguchi wrote:
    > I noticed that some error messages have issues such as non-standard
    > wording, slightly odd output, and minor grammatical mistakes, and have
    > attached patches addressing each of the items below.
    
    In the set of patches that Horiguchi-san has sent, I have taken care
    of 0006 as it was my own business.
    
    Added in CC the two committers that own the other items reported.
    
    Sawada-san, could you take care of 0001 as effective_wal_level is your
    thing?
    
    Alexander-san, could you take take of 0002~0005?  These relate to the
    WAIT command and the partition manipulation patches.
    
    Thanks,
    --
    Michael
    
  10. Re: Miscellaneous message fixes

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-10T18:20:21Z

    On Mon, Mar 9, 2026 at 11:05 PM Michael Paquier <michael@paquier.xyz> wrote:
    >
    > On Tue, Feb 10, 2026 at 02:37:52PM +0900, Kyotaro Horiguchi wrote:
    > > I noticed that some error messages have issues such as non-standard
    > > wording, slightly odd output, and minor grammatical mistakes, and have
    > > attached patches addressing each of the items below.
    >
    > In the set of patches that Horiguchi-san has sent, I have taken care
    > of 0006 as it was my own business.
    >
    > Added in CC the two committers that own the other items reported.
    >
    > Sawada-san, could you take care of 0001 as effective_wal_level is your
    > thing?
    
    Sure, I'll take care of it.
    
    Regards,
    
    -- 
    Masahiko Sawada
    Amazon Web Services: https://aws.amazon.com
    
    
    
    
  11. Re: Miscellaneous message fixes

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-10T18:39:33Z

    On Tue, Mar 10, 2026 at 11:20 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
    >
    > On Mon, Mar 9, 2026 at 11:05 PM Michael Paquier <michael@paquier.xyz> wrote:
    > >
    > > On Tue, Feb 10, 2026 at 02:37:52PM +0900, Kyotaro Horiguchi wrote:
    > > > I noticed that some error messages have issues such as non-standard
    > > > wording, slightly odd output, and minor grammatical mistakes, and have
    > > > attached patches addressing each of the items below.
    > >
    > > In the set of patches that Horiguchi-san has sent, I have taken care
    > > of 0006 as it was my own business.
    > >
    > > Added in CC the two committers that own the other items reported.
    > >
    > > Sawada-san, could you take care of 0001 as effective_wal_level is your
    > > thing?
    >
    > Sure, I'll take care of it.
    
    Pushed. Thank you for the report!
    
    Regards,
    
    -- 
    Masahiko Sawada
    Amazon Web Services: https://aws.amazon.com