On Mon, 7 Apr 2025 at 02:40, Andrew Dunstan <and...@dunslane.net> wrote: > > > On 2025-04-06 Su 1:51 PM, Tom Lane wrote: > > =?utf-8?Q?=C3=81lvaro?= Herrera <alvhe...@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
0001-pg_upgrade-add-alert-for-invalid-database-names.patch
Description: Binary data
