From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, adam(at)labkey(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Date: | 2024-12-02 23:16:19 |
Message-ID: | 1692919.1733181379@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-12-02 23:37:47 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Previous Message | Bruce Momjian | 2024-12-02 23:00:53 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |