Re: Size vs size_t or, um, PgSize?

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

On Mon, Jul 3, 2023 at 12:20 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 3 Jul 2023, at 21:14, Yurii Rashkovskii <yrashk@gmail.com> wrote:

> That being said, going ahead with the global renaming of Size to size_t will mostly eliminate this clash in, say, five years when old versions will be gone. At least it'll be fixed then. Otherwise, it'll never be fixed at all. To me, having the problem gone in the future beats having the problem forever.

I would also like all Size instances gone, but the cost during backpatching
will likely be very high.  There are ~1300 or so of them in the code, and
that's a lot of potential conflicts during the coming 5 years of backpatches.


I understand. How about a workaround for extension builders? Something like

```
/* Use this if you run into Size type redefinition */
#ifdef DONT_TYPEDEF_SIZE
#define Size size_t
#else
typedef size_t Size;
#endif
```
This way, extension developers can specify DONT_TYPEDEF_SIZE. However, this would have to be backported, but to minimal/no effect if I am not missing anything.

Not beautiful, but better than freezing the status quo forever?

--
Y.

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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Size vs size_t or, um, PgSize?
Следующее
От: Mikael Kjellström
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?