Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
От | Bruce Momjian |
---|---|
Тема | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Дата | |
Msg-id | Z048JXV9f8GczAUa@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
|
Список | pgsql-bugs |
On Mon, Dec 2, 2024 at 06:39:48PM +1300, Thomas Munro wrote: > Despite being a really simple idea for adding one new switch that > really only "stops" things rather than actually doing anything new, it > finishes up interacting with locking, logging, checkpointing, control > file, redo, grammar, pg_upgrade (and I see now that pg_dumpall might > need a similar approach), and I didn't even look at the startup stuff > you guys were working on that can hopefully benefit from having > GetSharedCatalogEncoding(). Hopefully the patch has the right sort of > ideas in some of those places, but obviously it's a rapid prototype so > might be way off on some of the details. It fails on Windows CI in a > very minor way that I see how to fix... later. It's enough to try out > the user experience anyway. Feedback, flames and ideas welcome. I am concerned we are going to get a lot of complaints about this restricted change because most people are happily using whatever encoding they want, and as long as they don't hit the 64-byte limit, they are fine. Are people going to be happy with this restriction just to keep 64+-byte identifiers safe? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"
В списке pgsql-bugs по дате отправления: