On Mon, Mar 29, 2021 at 11:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I'll move it when committing. I'll let this patch sit for another day
> > to see if any other objections show up.
>
> FWIW, I remain fairly strongly against this, precisely because of the
> point that it requires us to start using a randomly different
> feature-probing technology anytime Apple decides that they're going to
> implement some standard API that they didn't before.
This effectively works automatically as long as the feature check includes
the appropriate header. This works with AC_CHECK_DECLS or any
other autoconf probes that include the appropriate headers.
> Even if it works
> everywhere for preadv/pwritev (which we won't know in advance of
> buildfarm testing, and maybe not then, since detection failures will
> probably be silent), it seems likely that we'll hit some case in the
> future where this interacts badly with some other platform's weirdness.
Well part of the motivation for setting unguarded-availability-new is so
that we get a hard error instead of just a deployment target version
incompatibility warning, the current situation does actually result in
weird runtime errors, this change makes those much more obvious
build errors.
To ensure these errors surface quickly one could have some of the
buildfarm tests set different MACOSX_DEPLOYMENT_TARGET's
which should then hard error during the build if incompatible symbols are
accidentally included.
I don't think this is likely to cause issues for other platforms unless they use
the availability attribute incorrectly see: https://reviews.llvm.org/D34264
> We haven't claimed in the past to support MACOSX_DEPLOYMENT_TARGET,
> and I'm not sure we should start now. How many people actually care
> about that?
Seems kinda important for anyone who wants to build postgres
compatible with targets older than the host system.