Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Date
Msg-id 6ac601c7-9a72-d354-cfaa-03a66108c778@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 21.06.21 07:22, Thomas Munro wrote:
> I'm not personally against the proposed change.  I'll admit there is
> something annoying about Apple's environment working in a way that
> doesn't suit traditional configure macros that have been the basis of
> portable software for a few decades, but when all's said and done,
> configure is a Unix wars era way to make things work across all the
> Unixes, and most of them are long gone, configure itself is on the way
> out, and Apple's still here, so...

I think this change is perfectly appropriate (modulo some small cleanups).

The objection was that you cannot reliably use AC_CHECK_FUNCS (and 
therefore AC_REPLACE_FUNCS) anymore, but that has always been true, 
since AC_CHECK_FUNCS doesn't handle macros, compiler built-ins, and 
functions that are not declared, and any other situation where looking 
for a symbol in a library is not the same as checking whether the symbol 
actual works for your purpose.  This is not too different from the long 
transition from "does this header file exists" to "can I compile this 
header file".

So in fact the correct way forward would be to get rid of all uses of 
AC_CHECK_FUNCS and related, and then this problem goes away by itself.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values
Next
From: Andy Fan
Date:
Subject: Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)