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 1tE8TT-005Od8-Dp for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 14:48:03 +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 1tE8TR-00GUbL-PT for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 14:48:01 +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 1tE8TR-00GUb2-H3 for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 14:48:01 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tE8TO-0037T0-Fn for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 14:48:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=DAkNKN4q6gxHGALxp5NEat5/sG0c+3VRLotwpb7Bc8k=; b=SMxLo YdK6x9xtj8ZDjXcIJaMit+Z4u2G8p54bbpT0QSlqjz4NRgv7dJF0QCiFg2zd9DlPiLvdwt1cHSNIn I6d+TwUQkUxHf1CaSFdKk4niYWH6PnjNx8QvSHR93vZ1EJHL9DhBrIFiuLGXt9h4ERGpjuqAW4I12 h0TmQpcPThsbroM7Ycr3ZH+XF5mnQEPuHTF42Wciy3n7n/sOOpyc6qb+uUk9jbtyDUzELQc6VJCKj 2HDbDjKwN3KHj8xUeLlqHnJo0SFrceJJTlnQ3unZtu22Qlh93ch4XIdagaUWRHFR2Vs8Azfq5CjQ5 UZm6A3+wCk/5j7S837t+j7AUJQybg==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1tE8TM-0004Ui-1P; Thu, 21 Nov 2024 09:47:56 -0500 Date: Thu, 21 Nov 2024 09:47:56 -0500 From: Bruce Momjian To: Bertrand Drouvot Cc: Nathan Bossart , Tom Lane , 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 Message-ID: References: <75265.1732076593@sss.pgh.pa.us> <154104.1732118090@sss.pgh.pa.us> <158506.1732120196@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Nov 21, 2024 at 02:35:50PM +0000, Bertrand Drouvot wrote: > On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote: > > I don't understand this logic. Why are two bytes important? If we knew > > it was UTF8 we could check for non-first bytes always starting with > > bits 10, but we can't know that. > > I think this is because this is a reliable way to detect if the truncation happened > in the middle of a character, without needing to know the specifics of the encoding. > > My understanding is that the key insight is that in any multibyte encoding, all > bytes within a multibyte character will have their high bits set. > > That's just my understanding from the code and Tom's previous explanations: I > might be wrong as not an expert in this area. 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. Also, do we really expect there to be trailing multi-byte characters and then some ASCII before it? Isn't it likely it will be all ASCII or all multi-byte characters? I guess for Latin1, it would work fine, but I assume for Asian languages, it will be almost all multi-byte characters. I guess digits would be ASCII. This all just seems very unfocused. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"