From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18711: Attempting a connection with a database name longer
 than 63 characters now fails
In-reply-to: <Zz0WPCEzx-mPvUxA@nathan>
References: <18711-7503ee3e449d2c47@postgresql.org>
 <3072825.1731866414@sss.pgh.pa.us> <Zzzdc1QLIuFoiTvE@nathan>
 <3796535.1732044807@sss.pgh.pa.us> <Zz0WPCEzx-mPvUxA@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Tue, 19 Nov 2024 16:50:36 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3976664.1732057784.1@sss.pgh.pa.us>
Date: Tue, 19 Nov 2024 18:09:44 -0500
Message-ID: <3976665.1732057784@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3976665.1732057784%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Nov 19, 2024 at 02:33:27PM -0500, Tom Lane wrote:
>> I did think of a way that we could approximate encoding-correct
>> truncation here, relying on the fact that what's in pg_database
>> is encoding-correct according to somebody:
>> ...

> That's an interesting idea.  That code would probably need to live in
> GetDatabaseTuple(), but it seems doable.  We might be able to avoid the
> "mighty improbable" case by always truncating up to
> MAX_MULTIBYTE_CHAR_LEN-1 times and failing if there are multiple matches,
> too.

Hmm ... but with short characters (e.g. LATIN1) there might be
legitimately-different names that that rule would complain about.
Still, the workaround remains "so spell it like it is in the catalog".
On balance I think that's an improvement over what I was visualizing.

Also, we could bypass the multiple lookups unless both the
NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which
should be rare enough to make it not much of a performance issue.

One annoying point is that we also need this for role lookup.

			regards, tom lane