Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, adam@labkey.com, pgsql-bugs@lists.postgresql.org
Date: 2024-11-21T14:35:50Z
Lists: pgsql-bugs
Hi, On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote: > On Thu, Nov 21, 2024 at 07:27:22AM +0000, Bertrand Drouvot wrote: > > + /* > > + * If the original name is too long and we see two consecutive bytes > > + * with their high bits set at the truncation point, we might have > > + * truncated in the middle of a multibyte character. In multibyte > > + * encodings, every byte of a multibyte character has its high bit > > + * set. So if IS_HIGHBIT_SET is true for both NAMEDATALEN-1 and > > + * NAMEDATALEN-2, we know we're in the middle of a multibyte > > + * character. We need to try truncating one more byte back to find the > > + * start of the next character. > > + */ > ... > > + /* > > + * If we've hit a byte with high bit clear (an ASCII byte), we > > + * know we can't be in the middle of a multibyte character, > > + * because all bytes of a multibyte character must have their > > + * high bits set. Any following byte must therefore be the > > + * start of a new character, so we can stop looking for > > + * earlier truncation points. > > + */ > > 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. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Revert "Don't truncate database and user names in startup packets."
- d09fbf645ece 17.3 landed
- a0ff56e2d3ff 18.0 landed
-
Don't truncate database and user names in startup packets.
- 562bee0fc13d 17.0 cited
-
Truncate incoming username and database name to NAMEDATALEN-1 characters
- d18c1d1f5102 7.1.1 cited