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