Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails

On Sat, Nov 23, 2024 at 08:37:18AM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Nov 22, 2024 at 02:01:41PM -0600, Nathan Bossart wrote:
> > On Fri, Nov 22, 2024 at 02:23:47PM -0500, Tom Lane wrote:
> > > 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.
> >
> > That's fine with me.
>
> +1
>
> > > 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.)
> >
> > Looks reasonable to me. I had been thinking of ways to simplify this code
> > based on Bruce's feedback, and I came up with the attached. If nothing
> > else, this at least helps minimize the amount of code that is only reached
> > in extremely rare cases, but it's probably not quite as performant as v4
> > for the usual path, so v4 may still be the way to go.
>
> Yeah, so what about v6 attached ("mixing" v4 and v5 by using a fast path in
> case the name is short enough).

v7 attach is even better than v6.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com