Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
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:21:16Z
Lists: pgsql-bugs
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. -- Bruce Momjian <bruce@momjian.us> 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?"
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