From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Size vs size_t |
Date: | 2017-03-16 21:39:55 |
Message-ID: | 20170316213955.2hu2fadka5vywdid@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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:
> >>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2017-03-16 21:42:29 | Re: Making clausesel.c Smarter |
Previous Message | David Steele | 2017-03-16 21:32:48 | Re: PL/Python: Add cursor and execute methods to plan object |