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: Bruce Momjian <bruce@momjian.us>
Cc: Thomas Munro <thomas.munro@gmail.com>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-12-03T01:41:01Z
Lists: pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes: > On Mon, Dec 2, 2024 at 06:16:19PM -0500, Tom Lane wrote: >> Reality is that using multiple encodings in shared catalogs just plain >> doesn't work very well. Even something as simple as "select datname >> from pg_database" is likely to give garbage if there are entries in >> encodings that don't match your current database's encoding. What >> Thomas is proposing is to formalize and then enforce the two usage >> patterns that we know work okay. > I have not heard of anyone complaining about the problem of viewing the > shared catalog columns so I didn't consider that benefit. That's probably because they've learned the hard way to use one of the two usage patterns that actually work. Also, I think we have some code around pg_stat_activity that suppresses possibly-wrongly-encoded data from other DBs (in query text, not only user/DB names). That suppression could be relaxed in the only-one-encoding mode, which would be a genuinue benefit. 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