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

On 2025-04-06 Su 1:51 PM, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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