Re: Size vs size_t or, um, PgSize?

Hi Thomas,

On Mon, Jul 3, 2023 at 12:03 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Tue, Jul 4, 2023 at 6:46 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > > On 3 Jul 2023, at 20:32, Yurii Rashkovskii <yrashk(at)gmail(dot)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.