Re: Size vs size_t

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On 2017-03-16 16:59:29 -0400, Robert Haas wrote:
>>> I guess I assumed that we wouldn't have defined PG-specific types if
>>> we wanted to just use the OS-supplied ones.

>> I think, in this case, defining Size in the first place was a bad call
>> on behalf of the project.

The short answer to that is that "Size" predates the universal acceptance
of size_t. If we were making these decisions today, or anytime since the
early 2000s, we'd surely have just gone with size_t. But it wasn't a
realistic option in the 90s.

> Well, I don't think we want to end up with a mix of Size and size_t in
> related code. That buys nobody anything. I'm fine with replacing
> Size with size_t if they are always equivalent, but there's no sense
> in having a jumble of styles.

I'm not in a hurry to do "s/Size/size_t/g" because I'm afraid it'll create
a lot of merge pain for back-patching, while not actually buying anything
much concretely. I think this falls under the same policy we use for many
other stylistic details, ie make new code look like the code right around
it. But I'm fine with entirely-new files standardizing on size_t.

regards, tom lane