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  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Re: ProcessStartupPacket(): database_name and user_name truncation  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: EBCDIC sorting as a use case for ICU rules
Следующее
От: Egor Chindyaskin
Дата:
Сообщение: Re: Stack overflow issue