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

  1. Revert "Don't truncate database and user names in startup packets."

  2. Don't truncate database and user names in startup packets.

  3. Truncate incoming username and database name to NAMEDATALEN-1 characters