Re: Size vs size_t or, um, PgSize?

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

> This used to be a typedef for unsigned int a very long time ago.

I'm fairly sure that Size dates from before we could expect the system
headers to provide size_t everywhere.

> 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.

Yeah. The code-churn costs of s/Size/size_t/g outweigh the possible
gain, at least from our admittedly project-centric point of view.
But I don't have a whole lot of sympathy for arguments about "this
other code I'd like to also use has its own definition for Size",
because you could potentially make that complaint about just about
every typedef we've got. If you have conflicts like that, you have
to resolve them by methods like #define hacks or factoring your code
so it doesn't need to include Postgres headers in the same files that
include $other-project-headers.

regards, tom lane