Re: Escape CR/LF in invalid database, role, and tablespace name errors

> On Jul 2, 2026, at 16:00, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> Hello,
>
> At Thu, 2 Jul 2026 12:16:34 +0800, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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 topic that 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 tablespace names because they frequently cause problems. This patch only escapes CR/LF in these object names when an error occurs, 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/