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

From Tom Lane
Subject Re: Should we work around msvc failing to compile tab-complete.c?
Date
Msg-id 1607739.1720561467@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should we work around msvc failing to compile tab-complete.c?  (Andres Freund <andres@anarazel.de>)
Responses Re: Should we work around msvc failing to compile tab-complete.c?
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2024-07-09 09:14:33 +0100, Dave Page wrote:
>> 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.

One thing that struck me while looking at tab-complete.c just now is
that there are aspects of the readline API that require strings to be
malloc'd by the client (tab-complete.c) and later free'd within
libreadline.  I wonder how that will play with Windows' weird rules
about when one DLL's malloc pool will interoperate with another's
(cf PQfreemem).  Worst case: the reason no one uses readline under
Windows is that it flat out doesn't work.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Erik Wienhold
Date:
Subject: Re: XML test error on Arch Linux
Next
From: Nathan Bossart
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation