Re: Cleaning up historical portability baggage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 14:09:22
Message-ID: 1522407.1657634962@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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 concur with your point that it's not great to use the standard name
for a function that doesn't have exactly the standard semantics.
But if it does, using a nonstandard name is not better. It's just one
more thing that readers of our code have to learn about.

Note that "exactly" only needs to mean "satisfies all the promises
made by POSIX". If some caller is depending on behavior details not
specified in the standard, that's the caller's bug not the wrapper
function's. Otherwise, yeah, we couldn't ever be sure whether a
wrapper function is close enough.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-07-12 14:12:49 pgsql: Add copy/equal support for XID lists
Previous Message Sergey Dudoladov 2022-07-12 13:52:58 Introduce "log_connection_stages" setting.