Re: Escape CR/LF in invalid database, role, and tablespace name errors - Mailing list pgsql-hackers

From Chao Li
Subject Re: Escape CR/LF in invalid database, role, and tablespace name errors
Date
Msg-id 417FA347-2517-4CA7-87A3-835A84D7C6EF@gmail.com
Whole thread
In response to Re: Escape CR/LF in invalid database, role, and tablespace name errors  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

> On Jul 2, 2026, at 16:00, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
>
> Hello,
>
> At Thu, 2 Jul 2026 12:16:34 +0800, Chao Li <li.evan.chao@gmail.com> wrote in
>> While testing “[b380a56a3] Disallow CR and LF in database, role, and
>> tablespace names”, I saw that CR/LF are properly rejected. However,
>> the raw problematic names are printed directly in the error message,
>> which can also reach the server log. This causes LF to split the
>> error message and CR to overwrite/hide the beginning of the message,
>> which seems not good.
>
> This does not seem specific to this change.  PostgreSQL log entries can
> already contain embedded newlines, most notably in logged query text.
>
> For example, if I enter the following in psql:
>
> =# select 'abcdef
> ghijk' 1;
>
> the server log contains:
>
> ERROR:  syntax error at or near "1" at character 23
> STATEMENT:  select 'abcdef
>         ghijk' 1;
>
>
>> And server log looks like:
>> ```
>> 2026-07-02 10:57:51.518 CST [96799] ERROR:  role name "a
>> b" contains a newline or carriage return character
>> ```
> ...
>> As shown above, printing the raw name in the error message can make
>> the log entry confusing: LF splits the error message across multiple
>> lines, while CR can overwrite the beginning of the line and lose
>> information.
>
> Also, as far as I can see, PostgreSQL has long printed user-supplied
> strings in error messages without escaping control characters in many
> places. While this is not exactly the same issue, we still allow table
> names containing ASCII control characters other than CR and LF.
>
> In short, this seems consistent with PostgreSQL's current design.
>

Thanks for your comment. I realized that STATEMENT logs don’t escape control characters, and I think that is a separate
topicthat this patch doesn’t try to touch. 

The scope of this patch is narrow. This patch is based on b380a56a3, which blocks CR/LF from database, role, and
tablespacenames because they frequently cause problems. This patch only escapes CR/LF in these object names when an
erroroccurs, which makes the error logs, as well as pg_upgrade’s report files, easier to read. 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Deadlock detector fails to activate on a hot standby replica
Next
From: Amit Kapila
Date:
Subject: Re: Fix publisher-side sequence permission reporting