On 2017-03-16 17:24:17 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund <and...@anarazel.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.
Just out of curiosity I checked when we switched to backing Size with size_t: 1998 - 0ad5d2a3a886e72b429ea2b84bfcb36c0680f84d > > 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. That seems like sane policy. I'm a bit doubtful that the pain would be all that bad, but I'm also not wild about trying. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers