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: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Bruce Momjian <bruce@momjian.us>, adam@labkey.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-11-22T19:23:47Z
Lists: pgsql-bugs
Attachments
- v4-attempt-multibyte-aware-truncation.patch (text/x-diff) patch v4
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes: > What about something like in v3 attached? (I did a few tests and that seems to > work as expected). After more thought I don't really like the idea of failing if there are multiple matches. It means that we might fail in cases where pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the right truncation point). ISTM the entire point of this patch is to restore the pre-v17 behavior as much as possible, so that seems like the wrong outcome. So that means we could do something like the attached. (There's room for argument about which error messages in InitPostgres should use in_dbname versus the truncated name, but I chose to use in_dbname for the two "does not exist" reports.) I didn't try to write a test case, but we probably should have one. 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