Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CA+hUKGLLJUMDgCzOK5K4NE6PpU87Ka7t7RQsZoZAZ_EKfL5L+A@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Cleaning up historical portability baggage
Re: Cleaning up historical portability baggage
List pgsql-hackers
On Tue, Jul 12, 2022 at 4:46 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I don't think that 0001 is buying us a whole lot, really. I prefer the
> style where we have PG-specific functions that behave differently on
> different platforms to the one where we call something that looks like
> a native OS function call on all platforms but on some of them it is
> secretly invoking a replacement implementation in src/port. The
> problem with the latter is it looks like you're using something that's
> universally supported and works the same way everywhere, but you're
> really not. If it were up to me, we'd have more pg_whatever() that
> calls whatever() on non-Windows and something else on Windows, rather
> than going in the direction that this patch takes us.

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?

AFAIK we generally only use pg_whatever() when there's a good reason,
such as an incompatibility, a complication or a different abstraction
that you want to highlight to a reader.  The reason here was
temporary: we couldn't implement standard pread/pwrite perfectly on
ancient HP-UX, but we *can* implement it on Windows, so the reason is
gone.

These particular pg_ prefixes have only been in our tree for a few
years and I was hoping to boot them out again before they stick, like
"Size".  I like using standard interfaces where possible for the very
basic stuff, to de-weird our stuff.

> I like all of the other patches. Reducing the number of configure
> tests that we need seems like a really good idea.

Thanks for looking.  Yeah, we could also be a little more aggressive
about removing configure tests, in the cases where it's just Windows
vs !Windows.  "HAVE_XXX" tests that are always true on POSIX systems
at the level we require would then be unnecessary.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Next
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum