Message-ID: <d49406e0-68af-4d2b-a604-2b7e2ccead03@dunslane.net>
Date: Sun, 6 Apr 2025 17:10:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
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
To: Tom Lane <tgl@sss.pgh.pa.us>, =?UTF-8?Q?=C3=81lvaro_Herrera?=
 <alvherre@alvh.no-ip.org>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 Mahendra Singh Thalor <mahi6run@gmail.com>,
 Srinath Reddy <srinath2133@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <202504061734.mtvroeo3gn33@alvherre.pgsql>
 <2967167.1743961909@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAmwQTAQgARQIbAwIX
 gAIZAQULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUC
 ZFlxxwUJGVGAbgAKCRCZ+n/LWfw7gXikB/9ZdcUy6CTBFIIuL/bVsc1eLEW/gJBjJBF6HxNY
 xgEkAgXAp4Lg4A5U+QB9GouFr7+GYxF0BU4hzoGhNPUWltxnHdMWP8nC/38LAqgMi8L/bbsm
 HW5YPBdWYaAZAPJQVfOAgjTbRUb26KSprpyrrJKW0ZmrZfjhNPcQ72jpWzoPLQqx2X6B0fru
 1jq+cBh8lb6r1mJTim1T3JIn+F/v5VpdQS+EL8xqsHkfzKjIPsW3CIXpkypSk6saA55Rkkbl
 26AW8ftPVB0Q6Lnn6FLt9CP0MGNixBQ55yq8r1K+nCBvCCjvQjM8RDm0UUum0WNl+ifQgTLO
 E8TWEnwVtkBf+3QWzsBNBE7KWFkBCADRnOM0FCzsYW6jtncg+dWIagjUZpvaClmqn/sJluLa
 Q3v1VXMQJzYs3eC1gh386W+XBwLRpDj3jzH81lX+p73Re3d3oJW7X+ffsxuzu5ZVdMUkqBYo
 nkAbKxr6gyJ12F/+JkUVzLcoTN+d/7YsQvUVi7NaKH8mJgjz112O4fUe3p9wfAaFa0RXHc5S
 GPzRTYRRlv/XZBIho4J2tkZOnteZJZ+GbxQVlINt6fd8P6al3MWOvpP/ExJPguEfjOsO6Njy
 xjo3WfpD4lHMOR/Oc3/8mScEF84rF2jXbsFgelWnbPWAvXY+pD0dXOFRkagGmC/viwBDqq5b
 5tk76kKmUbZxABEBAAHCwHwEGAEIACYCGwwWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUCZFlx
 5wUJGVGAjgAKCRCZ+n/LWfw7gf+iB/4g8CPY5jihf5r/8EsoIGe2H+dpVmpPF8YGBzTIvCz/
 fQoOq8AX/pE76QEuFnFZWfjw+wgBXgCVmkox2Eflkk6z4ND3pcwGZ6CfCxTQCDk/dij+2DQ4
 6bmDCy/sBgcbz9mTpoLC11HLoPae6YN9nBNQRZDcEFEu54OaVOqlIdbA6m+POIBCXZdHOFc0
 WoDTgxHRzC1jgQNidyd6tKqcsVJs0dzF0oKTmFFmUAqTdJO12LBuNA1rlqrR3EtpYk8B/wtS
 5dIMD7Q8hwQpL+4C6GNpb6ZKnPkLi47pDOLhz2qBrqN+rqUEsT3YnExYpzj5yOBi+FlmV1Hw
 49QYe1sn2ZPs
In-Reply-To: <2967167.1743961909@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/d49406e0-68af-4d2b-a604-2b7e2ccead03%40dunslane.net>
Precedence: bulk


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