public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Álvaro Herrera <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Mahendra Singh Thalor <[email protected]>
Cc: Srinath Reddy <[email protected]>
Cc: [email protected]
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
Date: Sun, 06 Apr 2025 13:51:49 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

=?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> 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.)

			regards, tom lane

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  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
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox