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: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Bruce Momjian <bruce@momjian.us>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-27T18:17:18Z
Lists: pgsql-bugs
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes: > Indeed, reverting might be the way to go then (without waiting for more 17 > behavior reports). I have an idea that might salvage something from what we've just been doing. The biggest single problem with the old behavior, AIUI, was the possibility of sending back encoding-corrupt names in connection failure reports. How about something like: * Don't truncate the names on sight (so we keep 562bee0fc1). * Truncate the names at NAMEDATALEN-1 just before catalog lookup (this restores the old lookup behavior, solving the current report). * In lookup-failure messages, be sure to report the un-truncated name (avoiding the bad-encoding problem). * Copy the correctly-truncated names from the catalog to any persistent storage such as MyProcPort, so that those are used for all post-connection purposes. 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