On Mon, Jan 13, 2025 at 05:51:54PM -0500, Tom Lane wrote:
> It's fair to worry about this, but I don't think my testing that would
> prove a lot. AFAICS, whether somebody runs into trouble would depend
> on many factors like their specific build process and what versions of
> which packages they have installed.
>
> In any case, I think we have a very limited amount of wiggle room.
> We definitely cannot change libpq's ABI without provoking howls of
> anguish.
Fair point.
> I have been wondering whether it would help to add something like
> this at the end of port/pqsignal.c in the back branches:
>
> #ifdef FRONTEND
> #undef pqsignal
>
> /* ABI-compatibility wrapper */
> pqsigfunc
> pqsignal(int signo, pqsigfunc func)
> {
> return pqsignal_fe(signo, func);
> }
> #endif
>
> (plus or minus an extern or so, but you get the idea). The point of
> this is that compiling against old headers and then linking against
> newer libpgport.a would still work. It does nothing however for the
> reverse scenario of compiling against new headers and then linking
> against old libpgport.a. So I haven't persuaded myself that it's
> worth the trouble -- but I'm happy to include it if others think
> it would help.
After sleeping on it, I think I agree that the extra gymnastics aren't
worth it to partially fix something that wasn't supported anyway. But I'm
not mortally opposed to it if someone feels strongly that it should be
included.
--
nathan
