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

  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