Nathan Bossart <nathandbossart@gmail.com> writes:
> On Mon, Jan 13, 2025 at 05:51:54PM -0500, Tom Lane wrote:
>> (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.
After more thought I've realized that the asymmetrical detection
here isn't all that bad, because the outcomes are different.
If we fail to catch old-headers-and-new-library, the result will
either be a link failure or (if the extension uses libpq) silently
linking to libpq's pqsignal, which was likely not what was intended.
If we fail to catch the other case, the result is always a link
failure, and that will happen at build time not in the field.
So now I'm inclined to include the ABI-compatible wrapper, which
will ensure that extensions continue to link to libpgport's pqsignal.
regards, tom lane
