From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(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-11-20 15:39:35 |
Message-ID: | 152768.1732117175@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote:
>> 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.
Yeah, you can't really assume that a database's name is stored using
the encoding of that database. And even if you did, you still can't
make any assumptions about pg_role. I doubt we want to do this
differently for roles than databases.
We've had some past discussions about tightening all this up, like
insisting that names in shared catalogs are always in UTF8. But
there are downsides to that too.
In any case, there is no way that a seqscan of pg_database (or
pg_role) is going to be adequately performant, let alone faster
than at-most-four indexed probes. We just had somebody inquiring
about whether it'd be okay to create a million roles...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-11-20 15:48:27 | Re: BUG #18717: ALTER ROLE SET ROLE functionality is broken |
Previous 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 |