Re: Should we work around msvc failing to compile tab-complete.c?

Hi,

On 2024-07-09 09:14:33 +0100, Dave Page wrote:
> On Mon, 8 Jul 2024 at 21:08, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think we'd need to backpatch more for older branches. At least
> >
> > commit 3f28bd7337d
> > Author: Thomas Munro <tmunro(at)postgresql(dot)org>
> > Date: 2022-12-22 17:14:23 +1300
> >
> > Add work-around for VA_ARGS_NARGS() on MSVC.
> >
> >
> > Given that - afaict - tab completion never used to work with msvc, I think
> > it'd be ok to just do it in 17 or 16+17 or such. Obviously nobody is
> > currently
> > building with readline support for windows - not sure if any packager is
> > going
> > to go back and add support for it in older branches.
>
>
> Packagers aren't likely to be using readline, as it's GPL and it would have
> to be shipped with packages on Windows.

I'm not sure (I mean that literally, not as a way to state that I think it's
not as you say) it'd actually be *that* big a problem to use readline - sure
it'd make psql GPL, but that's the only thing using readline. Since psql
doesn't link to extensible / user provided code, it might actually be ok.

With openssl < 3.0 the mix between openssl and readline would be problematic,
IIRC the licenses aren't really compatible. But luckily openssl relicensed to
apache v2.

But that is pretty orthogonal to the issue at hand:

> They are more likely to be using libedit if anything. Not sure if that has
> any bearing on the compilation failure.

The compilation issue is entirely independent of readline vs libedit, the
too-long if-else-if-else-if chain is purely in our code. While the error
message (particularly the compiler crash) is suboptimal, I can't entirely
fault the compiler for not dealing with 700 else-ifs.

In fact the else-if chain is a problem for other compilers too, it seems to be
hitting something in the vicinity of O(n^2) in gcc.

Greetings,

Andres Freund