From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.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: <Zz4IJ041indld9jv@nathan>
References: <18711-7503ee3e449d2c47@postgresql.org>
 <3072825.1731866414@sss.pgh.pa.us> <Zzzdc1QLIuFoiTvE@nathan>
 <3796535.1732044807@sss.pgh.pa.us> <Zz0WPCEzx-mPvUxA@nathan>
 <3976665.1732057784@sss.pgh.pa.us> <Zz1bvchIEQPT6eTr@nathan>
 <75265.1732076593@sss.pgh.pa.us> <Zz4BxVqAZnWHFXFB@nathan>
 <154104.1732118090@sss.pgh.pa.us> <Zz4IJ041indld9jv@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Wed, 20 Nov 2024 10:02:47 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <158505.1732120196.1@sss.pgh.pa.us>
Date: Wed, 20 Nov 2024 11:29:56 -0500
Message-ID: <158506.1732120196@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/158506.1732120196%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> Upthread, you mentioned that we could bypass multiple lookups unless both
> the NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII.  But if
> there are encodings with the high bit set that don't require multiple bytes
> per character, then how can we do that?

Well, we don't know the length of the hypothetically-truncated
character, but if there was one then all its bytes must have had their
high bits set.  Suppose that the untruncated name has a 4-byte
multibyte character extending from the NAMEDATALEN-3 byte through the
NAMEDATALEN'th byte (counting in origin zero here):

	...61 irrelevant bytes... C1 C2 C3 C4 ...

The original CREATE DATABASE would have removed that whole character
and stored a name of length NAMEDATALEN-3:

	...61 irrelevant bytes...

In the connection attempt, when we
receive the untruncated name, we'll first try to truncate it to
NAMEDATALEN-1 bytes:

	...61 irrelevant bytes... C1 C2

We'll look that up and not find it.  At this point we remember that
C3 had the high bit set, and we note that C2 does too, so we try

	...61 irrelevant bytes... C1

That still doesn't work, but C1 still has the high bit set,
so we try

	...61 irrelevant bytes...

and find the match.

Now as for the shortcut cases: if C3 does not have the high bit set,
it cannot be part of a multibyte character.  Therefore the original
encoding-aware truncation would have removed C3 and following bytes,
but no more.  The character immediately before might have been one
byte or several, but it doesn't matter.  Similarly, if C2 does not
have the high bit set, it cannot be part of a multibyte character.
The original truncation would have removed C3 and following bytes,
but no more.

Another way to think about this is that without knowledge of the
encoding, we don't know whether a run of several high-bit-set
bytes represents one character or several.  But all the encodings
we support are ASCII extensions, meaning that any high-bit-clear
byte represents an ASCII character and is not part of a multibyte
character.  So it would have gotten truncated or not independently
of what's around it.

			regards, tom lane