Re: Cleaning up historical portability baggage

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up historical portability baggage
Date: 2022-07-12 17:33:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2022-07-12 08:01:40 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > Hmm, but that's not what we're doing in general. For example, on
> > Windows we're redirecting open() to a replacement function of our own,
> > we're not using "pg_open()" in our code. That's not an example based
> > on AC_REPLACE_FUNCS, but there are plenty of those too. Isn't this
> > quite well established?
> Yes. I just don't care for it.
> Sounds like I'm in the minority, though.

I agree with you, at least largely.

Redefining functions, be it by linking in something or by redefining function
names via macros, is a mess. There's places where we then have to undefine
some of these things to be able to include external headers etc. Some
functions are only replaced in backends, others in frontend too. It makes it
hard to know what exactly the assumed set of platform primitives is. Etc.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-07-12 17:42:07 Re: Reducing the chunk header sizes on all memory context types
Previous Message Tom Lane 2022-07-12 17:31:13 remove_useless_groupby_columns is too enthusiastic