Re: Hide exposed impl detail of wchar.c

(I hope you don't mind I'm reposting your reply -- I accidentally replied directly to you b/c phone)

> On Nov 21, 2023, at 11:56 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2023-11-21 10:11:18 -0500, Eric Ridge wrote:
>> On Mon, Nov 20, 2023 at 7:10 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

<snip>

>> And I don’t know that it makes much sense for Postgres to include such a
>> header into 3rd-party code anyways.
>
> Well, we want to expose such functionality to extensions. For some cases using
> full functions would to be too expensive, hence using static inlines. In case
> of exposing simd stuff, that means we need to include headers.

Sure. Probably not my place to make that kind of broad statement anyways. The "static inlines" are problematic for us in pgrx-land too, but that's a different problem for another day.

> I'm not against splitting this out of pg_wchar.h, to be clear - that's a too
> widely used header for, so there's a good independent reason for such a
> change. I just don't really believe that moving simd.h out of there will end
> the issue, we'll add more inlines using simd over time...

Yeah and that's why Jubilee is working with the bindgen folks to tighten this up for good.

(We tracked all of the pg16 betas and didn't run into this until after pg16 went gold. I personally haven't groveled through the git logs to see when this header/static inline was added, but we'd have reported this sooner had we found it sooner.)

eric