| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, 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 19:23:47 |
| Message-ID: | 659706.1732303427@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> writes:
> What about something like in v3 attached? (I did a few tests and that seems to
> work as expected).
After more thought I don't really like the idea of failing if there
are multiple matches. It means that we might fail in cases where
pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
right truncation point). ISTM the entire point of this patch is to
restore the pre-v17 behavior as much as possible, so that seems like
the wrong outcome.
So that means we could do something like the attached. (There's
room for argument about which error messages in InitPostgres
should use in_dbname versus the truncated name, but I chose to
use in_dbname for the two "does not exist" reports.)
I didn't try to write a test case, but we probably should have one.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v4-attempt-multibyte-aware-truncation.patch | text/x-diff | 4.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-11-22 20:01:41 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
| Previous Message | Maxim Orlov | 2024-11-22 14:54:33 | Re: [BUGS] BUG #10123: Weird entries in pg_stat_activity |