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 1tDmk0-003Akf-TA for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Nov 2024 15:35:40 +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 1tDmjz-006iiv-GI for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Nov 2024 15:35:39 +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 1tDmjz-006iim-7C for pgsql-bugs@lists.postgresql.org; Wed, 20 Nov 2024 15:35:39 +0000 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDmjx-002wbN-2N for pgsql-bugs@lists.postgresql.org; Wed, 20 Nov 2024 15:35:38 +0000 Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-4609967ab7eso14799631cf.3 for ; Wed, 20 Nov 2024 07:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732116935; x=1732721735; 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=CmyU5m05ztNhU/kUWzND+2+PEBPoG1pgK7cMsy82fNQ=; b=FNkNS6mqR08S+Qdpj2j5H8csXayjN0rGzbheKbPfUNtJU+8mSijqRIwiZUFoF4jY3a 58O33hLBMbuR8FaN/vf41NRQcWDMaZ3pW42ed68LdFbFURS4W0A82iCCHf+rGPV44D2M bNUCdh/VAC6NJh3Do4sF1cRQitIFtmasRzVyMqNsOSe/3bBZ61YTEkMvEu15LdXUvSPF MoQxX9H0S1UJ/JcF4TR1qA9EqT9w4kRDIClWAvk5BOHveAreMGH4A4zlQgxJU88u1uVj /Xf0N8rfZMVrKLX5GQjJu4s3lPs70IReCaI3aK/9UcRTiOViMQJaMxUG8+84IuCxXDMd udfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732116935; x=1732721735; 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=CmyU5m05ztNhU/kUWzND+2+PEBPoG1pgK7cMsy82fNQ=; b=H8xyAiItq6ST5SE8wIHSTpvwQtwqvlQrmt/h0YE+IKsLVHM0UJvsXz+HhXPPjgYJOO 4u5Vwo7QxvjMJOGIj9cyzjcKGDTcAlX+3LdijLYWmg6JooIP6YKwJsMK4eodFxZb+cT8 E6yL4Gm81lA/jaRAtR806k74uvYLuhcxAC3W3hssbbbJE0fNoDhcsLbk1tvYK9MDldNT sKXqioJrE5h+yaoNhV7jTiQ+EdJkWFE7RLsWVw6puyLIlo8UlCcJKgaqyqjUnIKVisvk c/HsYaC22Rr8FOI4f2P4M5BlNrn7KOl+4GN5eRZ6ZwaAhZAW630gTTc7tnvsErxxfVn8 saqw== X-Forwarded-Encrypted: i=1; AJvYcCW/xWNGWtFQu/PG0z/cfNYut2B0q6b+0bMO35kjubl+TVJaXqGWQQuDXIV+NctY1pDqqq/mQqsWQ4T1@lists.postgresql.org X-Gm-Message-State: AOJu0YxGnqv3L5WgzyLYBtuZHdMbOMbeCWWowpxE3oejDIf84pU1e3S5 Pic0FcxEfbZWtWHLwPWH8Lthwu7CpeoCVwEHSKB0nlnCqZ7sT+t4SIBrRA== X-Gm-Gg: ASbGncuZisiaGJRTxwNmXAhijL+1nvQWm+Pc3hemI3BWHyKc8FaBSzI+GJVa0cCpzfv a3qbq/D9em7qGDi/oKyJTgEvsO5VNIUeQbTcOTPP6iHHj8g2nA1wnHqiCLqUm8kJf02LK6WXDCy G5GxpygmSgwKcyY8XJC/PW9DADO6cMK4btUfZohu4a4y1bgMT51S8AIL8zQkcdO8RjxGR34+NCv Jb52zTWjWmsrJz07lIBoGiYtgPZzbiXGOYV4SxLHdDhgiMaZsj4lR6WfbX1BahOZg0e4sG6Hy+P x9m8AWtCY4sKJPQLRB6bhrZ9DMgqAs6F13wSgn6D X-Google-Smtp-Source: AGHT+IFlF4IHwBCSeizx5bELbpZRmEgER91XnUpBbM1pAYnlZ/FIeNxAfrjEUX6g3x36s4xsiuvMZw== X-Received: by 2002:a05:622a:a0d:b0:461:15a1:788c with SMTP id d75a77b69052e-464783a67dfmr35825521cf.26.1732116935511; Wed, 20 Nov 2024 07:35:35 -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-4646ac16061sm11191531cf.87.2024.11.20.07.35.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2024 07:35:35 -0800 (PST) Date: Wed, 20 Nov 2024 09:35:33 -0600 From: Nathan Bossart To: Tom Lane Cc: adam@labkey.com, Bertrand Drouvot , 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: <18711-7503ee3e449d2c47@postgresql.org> <3072825.1731866414@sss.pgh.pa.us> <3796535.1732044807@sss.pgh.pa.us> <3976665.1732057784@sss.pgh.pa.us> <75265.1732076593@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75265.1732076593@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 19, 2024 at 11:23:13PM -0500, Tom Lane wrote: > Nathan Bossart writes: >> I'm admittedly not an expert in the multi-byte code, but since there are >> encodings like LATIN1 that use a byte per character, don't we need to do >> multiple lookups any time the NAMEDATALEN-1'th byte is non-ASCII? > > I don't think so, but maybe I'm missing something. An important > property of backend-legal encodings is that all bytes of a multibyte > character have their high bits set. Thus if the NAMEDATALEN-2'th > byte does not have that, it is not part of a multibyte character. > That's also the reason we can stop if we reach a high-bit-clear > byte while backing up to earlier bytes. That's good to know. If we can assume that 1) all bytes of a multibyte character have the high bit set and 2) all multibyte characters actually require multiple bytes, then there are just a handful of cases that require multiple lookups, and we can restrict even those to some extent, too. -- nathan