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 | 1692919.1733181379@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
|
Список | pgsql-bugs |
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. regards, tom lane
В списке pgsql-bugs по дате отправления: