Subject: Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote

From: Andrew Dunstan <[email-masked]>
Date: Sun, 6 Apr 2025 17:10:51 -0400

On 2025-04-06 Su 1:51 PM, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <[email-masked]> writes:
>> On 2025-Apr-06, Tom Lane wrote:
>>> If we can cite the SQL standard then it's an entirely defensible
>>> restriction.
>> We can.  It says (in 5.2 <token> and <separator>)
>> <regular identifier> ::= <identifier body>
>> <identifier body> ::= <identifier start> [ <identifier part>... ]
>> <identifier part> ::= <identifier start> | <identifier extend>
>> <identifier start> ::= !! See the Syntax Rules.
>> <identifier extend> ::= !! See the Syntax Rules.
> Hmm, but that's about non-quoted identifiers, so of course their
> character set is pretty restricted.  What's of concern here is
> what's allowed in double-quoted identifiers.  AFAICS there's
> not much restriction: it can be any <nondoublequote character>,
> and SR 7 says
>
>      7) A <nondoublequote character> is any character of the source
>      language character set other than a <double quote>.
>
>          NOTE 115 — “source language character set” is defined in
>          Subclause 4.10.1, “Host languages”, in ISO/IEC 9075-1.
>
> The referenced bit of 9075-1 is pretty vague too:
>
>      No matter what binding style is chosen, SQL-statements are written
>      in an implementation-defined character set, known as the source
>      language character set. The source language character set is not
>      required to be the same as the character set of any character
>      string appearing in SQL-data.
>
> So I'm not really seeing anything there that justifies forbidding any
> characters.  However, I still think that if we're going to forbid CR
> or LF, we might as well go the whole way and forbid all the ASCII
> control characters; none of them are any saner to use in identifiers
> than those two.  (I'd be for banning &nbsp; and similar as well, on
> the same usability grounds as banning tabs, except that putting an
> encoding dependency into this rule will not end well.)

Sound like we have some work to do, and that's not going to happen in 24 
hours.

cheers

andrew

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

---

From: Mahendra Singh Thalor <[email-masked]>
Date: Thu, 10 Apr 2025 23:58:41 +0530

> Sound like we have some work to do, and that's not going to happen in 24

Hi,
As per above discussions, for v18, we will not do any change to server
side to fix the issue of \n\r in database names. But as a cleanup
patch, we can give an alert to the user by "pg_upgrade --check". As
per current code, pg_dump and pg_upgrade will fail with "shell
command" error but in the attached patch, we will give some extra info
to the user by "pg_upgrade --check" so that they can fix database
names before trying to upgrade.

Here, I am attaching a patch which will give a list of invalid
database names in "pg_upgrade --check". We can consider this as a
cleanup patch.

-- 
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 11 Apr 2025 09:47:49 -0500

> database names in "pg_upgrade --check". We can consider this as a

Are you proposing this for v18?  I think this is all v19 material at this
point.  Perhaps we could argue this is a bug fix that should be
back-patched, but IMHO that's a bit of a stretch.  I don't sense a
tremendous amount of urgency, either.

-- 
nathan

---

From: Mahendra Singh Thalor <[email-masked]>
Date: Tue, 24 Jun 2025 11:37:00 +0530

> tremendous amount of urgency, either.

Thanks Nathan for the review.

I want to re-start this thread for v19. I posted v06* patches in my
previous updates[1]. Please someone review it and let me know feedback.

v06 patches: v06_patches
<https://www.postgresql.org/message-id/CAKYtNAqC5pkjmh8UgvbNLtMyEVeKUtDF3_%2B9dvG9zb8YrhTJQQ%40mail.gmail.com>

[1] :
https://www.postgresql.org/message-id/CAKYtNAqC5pkjmh8UgvbNLtMyEVeKUtDF3_%2B9dvG9zb8YrhTJQQ%40mail.gmail.com