On Mon, 7 Apr 2025 at 02:40, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> 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 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
>
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
