Re: Hide exposed impl detail of wchar.c

Поиск
Список
Период
Сортировка
От Eric Ridge
Тема Re: Hide exposed impl detail of wchar.c
Дата
Msg-id 81DC55C7-FC70-4EF3-A4C7-43C429563C0A@gmail.com
обсуждение исходный текст
Ответ на Hide exposed impl detail of wchar.c  (Jubilee Young <workingjubilee@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Locks on unlogged tables are locked?!
Следующее
От: vignesh C
Дата:
Сообщение: Re: pg_upgrade and logical replication