Size vs size_t or, um, PgSize?

From: Yurii Rashkovskii <yrashk(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Size vs size_t or, um, PgSize?
Date: 2023-07-03 18:32:37
Message-ID: CA+RLCQzSkLrwscci4+u3eqymzbozXPdFt_TsU_dXPHvU4Px0dg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2023-07-03 18:33:32 Including a sample Table Access Method with core code
Previous Message Nathan Bossart 2023-07-03 18:19:14 Re: pgsql: Fix search_path to a safe value during maintenance operations.