From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Size vs size_t |
Date: | 2017-03-16 22:12:54 |
Message-ID: | CAEepm=0y67tAMmVkpfMu0LR0_OunE9uOkJJZSVbqLW6WuLj-uw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 17, 2017 at 10:39 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-03-16 17:24:17 -0400, Tom Lane wrote:
>> 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:
>> > 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.
Naive replacement in new files (present in master but not in 9.6) with
the attached script, followed by a couple of manual corrections where
Size was really an English word in a comment, gets the attached diff.
src/backend/access/hash/hash_xlog.c | 26 ++--
src/backend/replication/logical/launcher.c | 4 +-
src/backend/utils/misc/backend_random.c | 4 +-
src/backend/utils/mmgr/dsa.c | 94 ++++++-------
src/backend/utils/mmgr/freepage.c | 202 ++++++++++++++--------------
src/backend/utils/mmgr/slab.c | 34 ++---
src/include/lib/simplehash.h | 6 +-
src/include/replication/logicallauncher.h | 2 +-
src/include/utils/backend_random.h | 2 +-
src/include/utils/dsa.h | 10 +-
src/include/utils/freepage.h | 24 ++--
src/include/utils/relptr.h | 4 +-
12 files changed, 206 insertions(+), 206 deletions(-)
That might be just about enough for size_t to catch up...
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
Size-to-size_t.sh | application/x-sh | 159 bytes |
Size-to-size_t.patch | application/octet-stream | 46.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-03-16 22:20:33 | Re: multivariate statistics (v25) |
Previous Message | Tom Lane | 2017-03-16 22:00:11 | Re: Size vs size_t |