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 | 1865227.1732723416@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: > 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
В списке pgsql-bugs по дате отправления: