Re: [HACKERS] Size vs size_t - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Size vs size_t
Date
Msg-id CA+TgmoZ+_Qz3um7-5G1h6XBXAEGbGGj8_LePKc2QqVgcqkP9-Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Size vs size_t  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Size vs size_t  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-03-16 16:59:29 -0400, Robert Haas wrote:
>> On Thu, Mar 16, 2017 at 4:40 PM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>> > Noticing that the assembled hackers don't seem to agree on $SUBJECT in
>> > new patches, I decided to plot counts of lines matching \<Size\> and
>> > \<size_t\> over time.  After a very long run in the lead, size_t has
>> > recently been left in the dust by Size.
>>
>> 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.  It gains us absolutely nothing, but makes it
> harder to read for people that don't know PG all that well.  I think we
> should slowly phase out Size usage, at least in new code.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Size vs size_t
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)