Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
От | Tom Lane |
---|---|
Тема | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Дата | |
Msg-id | 3976665.1732057784@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Список | 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
В списке pgsql-bugs по дате отправления: