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>,
Bruce Momjian <bruce@momjian.us>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-27T16:03:36Z
Lists: pgsql-bugs
Nathan Bossart <nathandbossart@gmail.com> writes: > That being said, I'm growing quite uneasy about the size of this hack, and > I'm wondering if it would be better to leave it alone (perhaps with an > update to the release notes) or just revert commit 562bee0 until we have a > better way of dealing with multibyte characters in identifiers (e.g., > tracking their encoding). I suspect there are similar problems in other > places (e.g., pg_dumpall). Yeah, there is something to be said for reverting. There is nothing about our handling of non-ASCII characters in shared system catalogs that isn't squishy as heck, and yet there have been darn few field complaints over the many years it's been like that. Maybe trying to make this truncation issue better in isolation wasn't such a great plan. (If we recorded the encoding of names in shared catalogs then this particular issue would be far easier to solve, but then we have other problems to address --- particularly, what to do if a name in the catalog fails to convert to the encoding we are using.) 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