Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-22T04:53:49Z
Lists: pgsql-bugs
John Naylor <johncnaylorls@gmail.com> writes: > On Thu, Nov 21, 2024 at 2:27 PM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> 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. > Counterexample: Shift JIS -- I don't think we can short-circuit the full check. Shift JIS is not an allowed server-side encoding, for precisely that reason. This whole proposal is based on the assumption that the string we need to match in pg_database is valid in some server-side encoding. regards, tom lane
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