Size vs size_t or, um, PgSize?

Поиск
Список
Период
Сортировка
От Yurii Rashkovskii
Тема Size vs size_t or, um, PgSize?
Дата
Msg-id CA+RLCQzSkLrwscci4+u3eqymzbozXPdFt_TsU_dXPHvU4Px0dg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Size vs size_t or, um, PgSize?  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Hi,

I've run into an issue of a name clash with system libraries. Specifically, the `Size` type seems to be just an alias for `size_t` and, at least on macOS, it clashes with the core SDK, as it is also defined by MacTypes.h, which is used by some of the libraries one may want to use from within a Postgres extension.

While in my case, I believe I have a workaround, I couldn't find any rationale as to why we might want to have this alias and not use size_t. Any insight on this would be appreciated.

Would there be any sense in changing it all to size_t or renaming it to something else?

I understand that they will break some extensions, so if we don't want them to have to go through with the renaming, can we enable backward compatibility with a macro?

If there's a willingness to try this out, I am happy to prepare a patch.

--
Y.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Следующее
От: Hannu Krosing
Дата:
Сообщение: Including a sample Table Access Method with core code