On Fri, Mar 17, 2017 at 10:39 AM, Andres Freund <and...@anarazel.de> wrote: > 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: >> > 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
Size-to-size_t.sh
Description: Bourne shell script
Size-to-size_t.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
