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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-11-20 15:32:47
Message-ID: Zz4BH8z_Oby0gR5X@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote:
> On Wed, Nov 20, 2024 at 10:10:51AM -0500, Tom Lane wrote:
>> Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> writes:
>> > Could we rely on pg_encoding_max_length() instead of MAX_MULTIBYTE_CHAR_LEN? That
>> > would then work for short characters too IIUC.
>>
>> No. We don't know which encoding it is. Even if you wanted to say
>> "use the database encoding", we haven't identified the database yet.
>
> I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname
> and encoding from FormData_pg_database and start from there the comparison
> with the dbname passed as an argument to GetDatabaseTuple(). Thoughts?

I was wondering if we could use the database encoding to disambiguate if we
found multiple matches, but IIUC the identifier will be truncated using the
encoding of the database from which it was created. But hopefully this is
all rare enough in practice...

--
nathan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Nathan Bossart 2024-11-20 15:35:33 Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Previous Message Tom Lane 2024-11-20 15:32:09 Re: Build failure with GCC 15 (defaults to -std=gnu23)