Re: Size vs size_t or, um, PgSize?

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

On Mon, Jul 3, 2023 at 12:03 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Tue, Jul 4, 2023 at 6:46 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> > On 3 Jul 2023, at 20:32, Yurii Rashkovskii <yrashk@gmail.com> wrote:
> > If there's a willingness to try this out, I am happy to prepare a patch.
>
> This has been discussed a number of times in the past, and the conclusion from
> last time IIRC was to use size_t for new code and only change the existing
> instances when touched for other reasons to avoid churn.

One such earlier discussion:

https://www.postgresql.org/message-id/flat/CAEepm%3D1eA0vsgA7-2oigKzqg10YeXoPWiS-fCuQRDLwwmgMXag%40mail.gmail.com

I personally wouldn't mind if we just flipped to standard types
everywhere, but I guess it wouldn't help with your problem with
extensions on macOS as you probably also want to target released
branches, not just master/17+.  But renaming in the back branches
doesn't sound like something we'd do...

Of course, it would have been great to have it backported in the ideal world, but it isn't realistic, as you say. 

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.


--
Y.

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Size vs size_t or, um, PgSize?
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Size vs size_t or, um, PgSize?