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 | Z05Ey-8ABqWUQGYX@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:16:19PM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > 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? > > That's a remarkably rose-tinted view of the current state of affairs. > Reality is that using multiple encodings in shared catalogs just plain > doesn't work very well. Even something as simple as "select datname > from pg_database" is likely to give garbage if there are entries in > encodings that don't match your current database's encoding. What > Thomas is proposing is to formalize and then enforce the two usage > patterns that we know work okay. > > Moreover, the proposal also includes a third backwards-compatibility > mode that will let anyone who does like the current approach to keep > using it. So I'm unclear on why you think there's a big downside. I have not heard of anyone complaining about the problem of viewing the shared catalog columns so I didn't consider that benefit. -- 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 по дате отправления: