| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Yurii Rashkovskii <yrashk(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Size vs size_t or, um, PgSize? |
| Date: | 2023-07-03 19:20:49 |
| Message-ID: | 38CFFB13-CB71-439F-8B9E-9330C696768D@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 3 Jul 2023, at 21:14, Yurii Rashkovskii <yrashk(at)gmail(dot)com> wrote:
> That being said, going ahead with the global renaming of Size to size_t will mostly eliminate this clash in, say, five years when old versions will be gone. At least it'll be fixed then. Otherwise, it'll never be fixed at all. To me, having the problem gone in the future beats having the problem forever.
I would also like all Size instances gone, but the cost during backpatching
will likely be very high. There are ~1300 or so of them in the code, and
that's a lot of potential conflicts during the coming 5 years of backpatches.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yurii Rashkovskii | 2023-07-03 19:37:55 | Re: Size vs size_t or, um, PgSize? |
| Previous Message | Yurii Rashkovskii | 2023-07-03 19:14:00 | Re: Size vs size_t or, um, PgSize? |