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 1tEHGc-006VOs-8o for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Nov 2024 00:11:22 +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 1tEHGa-003A3y-Dj for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Nov 2024 00:11:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEHGa-003A2L-2k for pgsql-bugs@lists.postgresql.org; Fri, 22 Nov 2024 00:11:20 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEHGT-0038GG-1j for pgsql-bugs@lists.postgresql.org; Fri, 22 Nov 2024 00:11:18 +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 4AM0B911477093; Thu, 21 Nov 2024 19:11:09 -0500 From: Tom Lane To: Bruce Momjian cc: Bertrand Drouvot , Nathan Bossart , 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: <75265.1732076593@sss.pgh.pa.us> <154104.1732118090@sss.pgh.pa.us> <158506.1732120196@sss.pgh.pa.us> Comments: In-reply-to Bruce Momjian message dated "Thu, 21 Nov 2024 09:47:56 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <477091.1732234269.1@sss.pgh.pa.us> Date: Thu, 21 Nov 2024 19:11:09 -0500 Message-ID: <477092.1732234269@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bruce Momjian writes: > But the logic doesn't make sense. Why would two bytes be any different > than one? I assumed you would just remove all trailing high-bit bytes > and stop and the first non-high-bit byte. To take the most obvious counterexample: what if the name contains *only* high-bit-set bytes? In any case, this logic must achieve the same effect as the original encoding-aware truncation, which will not have removed more than it absolutely had to. regards, tom lane