Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Date
Msg-id 1692919.1733181379@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails