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
