Re: ProcessStartupPacket(): database_name and user_name truncation
От | Tom Lane |
---|---|
Тема | Re: ProcessStartupPacket(): database_name and user_name truncation |
Дата | |
Msg-id | 3756493.1687355018@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ProcessStartupPacket(): database_name and user_name truncation (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: ProcessStartupPacket(): database_name and user_name truncation
Re: ProcessStartupPacket(): database_name and user_name truncation |
Список | pgsql-hackers |
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. (Our whole story about what is the encoding of names in shared catalogs is a mess. But this particular point doesn't seem like the place to start if you want to clean that up.) regards, tom lane
В списке pgsql-hackers по дате отправления: