Re: Hide exposed impl detail of wchar.c - Mailing list pgsql-hackers

From Eric Ridge
Subject Re: Hide exposed impl detail of wchar.c
Date
Msg-id 81DC55C7-FC70-4EF3-A4C7-43C429563C0A@gmail.com
Whole thread Raw
In response to Hide exposed impl detail of wchar.c  (Jubilee Young <workingjubilee@gmail.com>)
List pgsql-hackers
(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@anarazel.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@anarazel.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
inpgrx-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
throughthe git logs to see when this header/static inline was added, but we'd have reported this sooner had we found it
sooner.)

eric


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Locks on unlogged tables are locked?!
Next
From: vignesh C
Date:
Subject: Re: pg_upgrade and logical replication