Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, adam@labkey.com, pgsql-bugs@lists.postgresql.org
Date: 2024-11-20T16:02:06Z
Lists: pgsql-bugs
On Wed, Nov 20, 2024 at 10:39:35AM -0500, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: > > On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote: > >> I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname > >> and encoding from FormData_pg_database and start from there the comparison > >> with the dbname passed as an argument to GetDatabaseTuple(). Thoughts? > > > I was wondering if we could use the database encoding to disambiguate if we > > found multiple matches, but IIUC the identifier will be truncated using the > > encoding of the database from which it was created. > > Yeah, you can't really assume that a database's name is stored using > the encoding of that database. Yeah, good point, let's stick to the MAX_MULTIBYTE_CHAR_LEN idea then and discard the usage of pg_encoding_max_length(). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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