On Thu, Nov 16, 2023 at 12:10:59PM -0800, Jubilee Young wrote:
> On the off-chance that everyone agrees with me without reserve, the
> attached patch moves the relevant code around (and includes the gory
> details). This seems to be unlikely to be the only mildly-exotic build
> system failure caused by such an overexposed implementation detail, so
> while I'm not married to this particular code motion, it seems best to
> improve this some way.
It looks like is_valid_ascii() was originally added to pg_wchar.h so that
it could easily be used elsewhere [0] [1], but that doesn't seem to have
happened yet.
Would moving this definition to a separate header file be a viable option?
That'd still break any existing projects that are using it, but at least
there'd be an easy fix. I'm not sure there _are_ any other projects using
it, anyway. However, both of these proposals feel like they might be
slightly beyond what we'd ordinarily consider back-patching.
That being said, it's not unheard of for Postgres to make adjustments for
third-party code (search for "pljava" in commits 62aba76 and f4aa3a1). I
read the description of the pgrx problem [2], and I'm still trying to
understand the scope of the issue. I don't think it's reasonable to expect
someone building an extension to always use the exact same compiler that
was used by the packager, but I also don't fully understand why different
compilations of an inline function would cause problems.
[0] https://postgr.es/m/CAFBsxsHG%3Dg6W8Mie%2B_NO8dV6O0pO2stxrnS%3Dme5ZmGqk--fd5g%40mail.gmail.com
[1] https://postgr.es/m/CAFBsxsH1Yutrmu%2B6LLHKK8iXY%2BvG--Do6zN%2B2900spHXQNNQKQ%40mail.gmail.com
[2] https://github.com/pgcentralfoundation/pgrx/issues/1298
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
