Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Nov 28, 2024 at 5:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (If we recorded the encoding of names in shared catalogs then this
>> particular issue would be far easier to solve, but then we have
>> other problems to address --- particularly, what to do if a name
>> in the catalog fails to convert to the encoding we are using.)

> Here is a much dumber coarse-grained way I have wondered about for
> making the encoding certain, without having to do any new conversions
> at all: (1) single-encoding cluster mode, shared catalogues use same
> encoding as all databases, (2) multi-encoding cluster mode with
> ASCII-only shared catalogues, and (3) legacy squishy/raw mode you
> normally only reach by pg_upgrade. Maybe you could switch between
> them with an operation that validates names.

Hmm, yeah maybe that could work. The other consideration here
(which we've been dancing around in this thread) is "what encoding
are role and database names in startup packets presented in?"
But I think your idea addresses that too:

* mode 1: incoming names must be in the One True Encoding

* mode 2: incoming names must be ASCII

* mode 3: same wild-west behavior as always

In modes 1 and 2 we could validate that the string meets our
expectations (and then truncate it correctly, too).

> I guess serious users of multi-encoding clusters already learn to
> stick to ASCII-only role names and database names anyway, unless they
> like seeing garbage?

Probably ... that's been the recommendation in the small number
of cases that have been reported, IIRC. That suggests that mode 2
might be the most reasonable default.

regards, tom lane