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

From Yurii Rashkovskii
Subject Size vs size_t or, um, PgSize?
Date
Msg-id CA+RLCQzSkLrwscci4+u3eqymzbozXPdFt_TsU_dXPHvU4Px0dg@mail.gmail.com
Whole thread Raw
Responses Re: Size vs size_t or, um, PgSize?
List pgsql-hackers
Hi,

I've run into an issue of a name clash with system libraries. Specifically, the `Size` type seems to be just an alias for `size_t` and, at least on macOS, it clashes with the core SDK, as it is also defined by MacTypes.h, which is used by some of the libraries one may want to use from within a Postgres extension.

While in my case, I believe I have a workaround, 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.

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.

--
Y.

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Next
From: Hannu Krosing
Date:
Subject: Including a sample Table Access Method with core code