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 1tEBhf-005n56-FB for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 18:14:55 +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 1tEBhe-000ByC-1O for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 18:14:54 +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 1tEBhd-000By4-O6 for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 18:14:53 +0000 Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tEBhb-0035gF-43 for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 18:14:52 +0000 Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-4609c9b39d0so7029861cf.1 for ; Thu, 21 Nov 2024 10:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732212890; x=1732817690; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WlaWy/AaZHisDlhkN/G2gb9ZENWPilbxbZlw0H1hGpo=; b=AiZdvwrtqenxOKaYDJ/FXXTwkfIKx02vGzcWUCeWCNG5aAaK7DkCgdRS/c958U5j/C Ja6u7bn6+Z1uxlCbAI7B4aJ3e2R3e0OoS/yla++zZzAoKGZLwCLsUUOXKTGX0JFv/0SG oX1M6tZIKM71V1ZK7Jkn402M5G9Hx2yLpSAc3tVqcXQbV6fghzTgROsz81bg3p/T0ZJJ hpwpsJz6CC24YpxWQhVySYEGDVyIIAaqHo5PTssUyk8P8Bfod65UlGPPejGMdDiOO6W4 3YXuGKumxVfTu6JJAiM0YbYAAIU8MTduNEPdIIDlafuDohPCd2umabADhK+MZwmpBtHZ 1jLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732212890; x=1732817690; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WlaWy/AaZHisDlhkN/G2gb9ZENWPilbxbZlw0H1hGpo=; b=l3Ox4r84JrQo43xXHYmFfd/pL5f8q67y649pNX+xZQg1BSXA+pTJO4WLDX4o4ta9L1 yfFqyej9oyIB39xWDQoKhFPAxHD1as7p2WccKpDcFI58kr+bTAGOy+sk6WiE+jAK5ddJ tEacfrd5oMr1KSeTDJlE7wiXS7wFdwMtGH5CNnzd8bWegsX1qlYhClZPfWBYfPEj1xwX OGu44zGNeYlevbj/oGrcMzS4oIUMbhusGFvkcHxnJW3+3rA7h7MNjOvTSH0ZhxpfLxJf 7S1Vr608CM0GpUHLF1QjbkjJTCe8HaVgqKC5zRlASQrlQIm0ZLujz3FuQ88W8njIHDDb Kgyg== X-Forwarded-Encrypted: i=1; AJvYcCUk/GG104ERHw1f8KDXhhaqQ4neDxG9o206NJnoKjJsfmcNaGiy3osH1ix7agtSKUx4RR2TcQRQbJ8S@lists.postgresql.org X-Gm-Message-State: AOJu0YzDIyy8tWsWBzQgSG7gwcUTlKs30KmR8wTVZunPH+DwW4k7aH4Z 9UZWa23Mgo9nS/EBapgKqmxfEpmJgSMo5cA8zfaTOIoUFnNWD6mG X-Gm-Gg: ASbGncs9Ak8BrKtkgO6z8FIcb/n2MegeyMvHZnw0/0JqTilmXhe+kdhcPqA0xqfdBli C4QWpJZV+zSekwWnIWo9inBVe2X5JeWewklIB0+R25VqMXVcwOAzfCkMUTGRKAOKjxq4A3FkFYc UPfY12b3W+XrxdPwfXb5edqgWo1cOBRgXYE8/VK00YNossikHiohPLtdNScnLvCGDdoYlZi5fWa Y21ftDXcXaNIdEyan00EfQj4nZgUBFRo2FO/5vMibySKm24Lsab2R8OliAubB08Fz7rhi9lDz/u G6cdTTvBmdaHfVGfl9JvscXOem4wiZoan3Cct6Md X-Google-Smtp-Source: AGHT+IG7iCpwVW41vbYhkiL63mSeKfITRgMrmbIZyeLmDGxsXCnXJiA+ephJSLMESiUQ6bzsiEeBCQ== X-Received: by 2002:ac8:5984:0:b0:460:3a44:e150 with SMTP id d75a77b69052e-4647a7e246bmr85670351cf.51.1732212889977; Thu, 21 Nov 2024 10:14:49 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4653c40a4d3sm1558051cf.44.2024.11.21.10.14.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Nov 2024 10:14:49 -0800 (PST) Date: Thu, 21 Nov 2024 12:14:47 -0600 From: Nathan Bossart To: Bruce Momjian Cc: Bertrand Drouvot , 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: 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 01:05:38PM -0500, Bruce Momjian wrote: > On Thu, Nov 21, 2024 at 11:09:14AM -0600, Nathan Bossart wrote: >> Yes, we still need to do that if it's possible the truncation wiped out >> part of a multi-byte character. But it's not possible that we truncated >> part of a multi-byte character if the NAMEDATALEN-1'th or NAMEDATALEN-2'th >> byte is ASCII, in which case we can avoid doing extra lookups. > > Why would you check for two characters at the end rather than just a > normal check in the main loop? It might be possible to integrate this check into the loop, which could potentially be cleaner. The reason I didn't at first is because it requires checking a byte that we will have already truncated away. We have to look at the original, non-truncated string for that. I'll give it a try (unless Bertrand beats me to it). >> What more do you think is required? > > I think the IS_HIGHBIT_SET needs to be integrated into the 'for' loop > more clearly; the 'if' check plus the comment above it is just > confusing. Got it. Thank you for reviewing. -- nathan