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-22T19:23:47Z
Lists: pgsql-bugs

Attachments

Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> What about something like in v3 attached? (I did a few tests and that seems to
> work as expected).

After more thought I don't really like the idea of failing if there
are multiple matches.  It means that we might fail in cases where
pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
right truncation point).  ISTM the entire point of this patch is to
restore the pre-v17 behavior as much as possible, so that seems like
the wrong outcome.

So that means we could do something like the attached.  (There's
room for argument about which error messages in InitPostgres
should use in_dbname versus the truncated name, but I chose to
use in_dbname for the two "does not exist" reports.)

I didn't try to write a test case, but we probably should have one.

			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