Re: Size vs size_t or, um, PgSize?

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



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

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