Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
От | Tom Lane |
---|---|
Тема | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Дата | |
Msg-id | 152768.1732117175@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
|
Список | pgsql-bugs |
Nathan Bossart <nathandbossart@gmail.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
В списке pgsql-bugs по дате отправления: