Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, adam@labkey.com, pgsql-bugs@lists.postgresql.org
Date: 2024-11-21T18:14:47Z
Lists: pgsql-bugs
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
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