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: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-19T23:09:44Z
Lists: pgsql-bugs
Nathan Bossart <nathandbossart@gmail.com> writes: > On Tue, Nov 19, 2024 at 02:33:27PM -0500, Tom Lane wrote: >> I did think of a way that we could approximate encoding-correct >> truncation here, relying on the fact that what's in pg_database >> is encoding-correct according to somebody: >> ... > That's an interesting idea. That code would probably need to live in > GetDatabaseTuple(), but it seems doable. We might be able to avoid the > "mighty improbable" case by always truncating up to > MAX_MULTIBYTE_CHAR_LEN-1 times and failing if there are multiple matches, > too. Hmm ... but with short characters (e.g. LATIN1) there might be legitimately-different names that that rule would complain about. Still, the workaround remains "so spell it like it is in the catalog". On balance I think that's an improvement over what I was visualizing. Also, we could bypass the multiple lookups unless both the NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which should be rare enough to make it not much of a performance issue. One annoying point is that we also need this for role lookup. 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