From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Yurii Rashkovskii <yrashk(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Size vs size_t or, um, PgSize? |
Date: | 2023-07-03 18:46:33 |
Message-ID: | 273B488E-71D6-4A99-A284-6FDE75B91775@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 3 Jul 2023, at 20:32, Yurii Rashkovskii <yrashk(at)gmail(dot)com> wrote:
> I couldn't find any rationale as to why we might want to have this alias and not use size_t. Any insight on this would be appreciated.
This used to be a typedef for unsigned int a very long time ago.
> Would there be any sense in changing it all to size_t or renaming it to something else?
>
> I understand that they will break some extensions, so if we don't want them to have to go through with the renaming, can we enable backward compatibility with a macro?
>
> If there's a willingness to try this out, I am happy to prepare a patch.
This has been discussed a number of times in the past, and the conclusion from
last time IIRC was to use size_t for new code and only change the existing
instances when touched for other reasons to avoid churn.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-07-03 18:53:52 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Previous Message | Thomas Munro | 2023-07-03 18:40:49 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |