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: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-20T15:39:35Z
Lists: pgsql-bugs
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. And even if you did, you still can't make any assumptions about pg_role. I doubt we want to do this differently for roles than databases. We've had some past discussions about tightening all this up, like insisting that names in shared catalogs are always in UTF8. But there are downsides to that too. In any case, there is no way that a seqscan of pg_database (or pg_role) is going to be adequately performant, let alone faster than at-most-four indexed probes. We just had somebody inquiring about whether it'd be okay to create a million roles... 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