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

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.
 
> 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.

I think we'll also want to do something about MyProcPort->database_name
(and the user name, of course).  In a previous patch, I tried to update it
when a match was found, but maybe it'd be better to postpone setting those
values at all until after we've found the database tuple.  AFAICT they are
only used for the process title before this code is reached.

-- 
nathan