| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, adam(at)labkey(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
| Date: | 2024-11-22 04:53:49 |
| Message-ID: | 509656.1732251229@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
John Naylor <johncnaylorls(at)gmail(dot)com> writes:
> On Thu, Nov 21, 2024 at 2:27 PM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> + * If the original name is too long and we see two consecutive bytes
> + * with their high bits set at the truncation point, we might have
> + * truncated in the middle of a multibyte character. In multibyte
> + * encodings, every byte of a multibyte character has its high bit
> + * set.
> Counterexample: Shift JIS -- I don't think we can short-circuit the full check.
Shift JIS is not an allowed server-side encoding, for precisely
that reason. This whole proposal is based on the assumption that
the string we need to match in pg_database is valid in some
server-side encoding.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2024-11-22 07:45:39 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
| Previous Message | John Naylor | 2024-11-22 04:39:15 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |