Re: Size vs size_t or, um, PgSize? - Mailing list pgsql-hackers

From Yurii Rashkovskii
Subject Re: Size vs size_t or, um, PgSize?
Date
Msg-id CA+RLCQznjC=EROmf9RbD=6ajvSi1zWy_56mk9+L0t6ftV9dNwQ@mail.gmail.com
Whole thread Raw
In response to Re: Size vs size_t or, um, PgSize?  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Daniel,

On Mon, Jul 3, 2023 at 12:20 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 3 Jul 2023, at 21:14, Yurii Rashkovskii <yrashk@gmail.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.


I understand. How about a workaround for extension builders? Something like

```
/* Use this if you run into Size type redefinition */
#ifdef DONT_TYPEDEF_SIZE
#define Size size_t
#else
typedef size_t Size;
#endif
```
This way, extension developers can specify DONT_TYPEDEF_SIZE. However, this would have to be backported, but to minimal/no effect if I am not missing anything.

Not beautiful, but better than freezing the status quo forever?

--
Y.

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Size vs size_t or, um, PgSize?
Next
From: Mikael Kjellström
Date:
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?