Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tGKWP-002HyB-J5 for pgsql-bugs@arkaria.postgresql.org; Wed, 27 Nov 2024 16:04:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tGKWN-00GQ2h-Fz for pgsql-bugs@arkaria.postgresql.org; Wed, 27 Nov 2024 16:04:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tGKWN-00GQ2Z-7I for pgsql-bugs@lists.postgresql.org; Wed, 27 Nov 2024 16:04:07 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tGKWK-004Lrk-Qb for pgsql-bugs@lists.postgresql.org; Wed, 27 Nov 2024 16:04:06 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4ARG3aK21865228; Wed, 27 Nov 2024 11:03:36 -0500 From: Tom Lane To: Nathan Bossart cc: Bertrand Drouvot , Bruce Momjian , adam@labkey.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails In-reply-to: References: <659706.1732303427@sss.pgh.pa.us> <665338.1732306066@sss.pgh.pa.us> Comments: In-reply-to Nathan Bossart message dated "Wed, 27 Nov 2024 09:40:13 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1865226.1732723416.1@sss.pgh.pa.us> Date: Wed, 27 Nov 2024 11:03:36 -0500 Message-ID: <1865227.1732723416@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > That being said, I'm growing quite uneasy about the size of this hack, and > I'm wondering if it would be better to leave it alone (perhaps with an > update to the release notes) or just revert commit 562bee0 until we have a > better way of dealing with multibyte characters in identifiers (e.g., > tracking their encoding). I suspect there are similar problems in other > places (e.g., pg_dumpall). Yeah, there is something to be said for reverting. There is nothing about our handling of non-ASCII characters in shared system catalogs that isn't squishy as heck, and yet there have been darn few field complaints over the many years it's been like that. Maybe trying to make this truncation issue better in isolation wasn't such a great plan. (If we recorded the encoding of names in shared catalogs then this particular issue would be far easier to solve, but then we have other problems to address --- particularly, what to do if a name in the catalog fails to convert to the encoding we are using.) regards, tom lane