From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | bertranddrouvot(dot)pg(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ProcessStartupPacket(): database_name and user_name truncation |
Date: | 2023-06-21 13:43:38 |
Message-ID: | 3756493.1687355018@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Wed, 21 Jun 2023 09:43:50 +0200, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Egor Chindyaskin | 2023-06-21 13:45:00 | Re: Stack overflow issue |
Previous Message | Daniel Verite | 2023-06-21 13:28:38 | EBCDIC sorting as a use case for ICU rules |