Re: ProcessStartupPacket(): database_name and user_name truncation
От | Drouvot, Bertrand |
---|---|
Тема | Re: ProcessStartupPacket(): database_name and user_name truncation |
Дата | |
Msg-id | e493eb79-8c8d-1a29-c1c3-730cf7d8d9b9@gmail.com обсуждение исходный текст |
Ответ на | Re: ProcessStartupPacket(): database_name and user_name truncation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ProcessStartupPacket(): database_name and user_name truncation
|
Список | pgsql-hackers |
Hi, On 6/21/23 3:43 PM, Tom Lane wrote: > Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes: >> At Wed, 21 Jun 2023 09:43:50 +0200, "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> wrote in >>> Trying to connect with the 64 bytes name: >>> $ psql -d ääääääääääääääääääääääääääääääää >>> psql: error: connection to server on socket "/tmp/.s.PGSQL.55448" >>> failed: FATAL: database "äääääääääääääääääääääääääääääää" does not >>> exist > >> IMHO, I'm not sure we should allow connections without the exact name >> being provided. In that sense, I think we might want to consider >> outright rejecting the estblishment of a connection when the given >> database name doesn't fit the startup packet, since the database with >> the exact given name cannot be found. > > I think I agree. I don't like the proposed patch at all, because it's > making completely unsupportable assumptions about what encoding the > names are given in. Simply failing to match when a name is overlength > sounds safer. > Yeah, that's another and "cleaner" option. I'll propose a patch to make it failing even for the non multibyte case then ( so that multibyte and non multibyte behaves the same aka failing in case of overlength name is detected). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: