Hide exposed impl detail of wchar.c - Mailing list pgsql-hackers

From Jubilee Young
Subject Hide exposed impl detail of wchar.c
Date
Msg-id CAPNHn3oKJJxMsYq+qLYzVJOFrUcOr4OF1EC-KtFT-qh8nOOOtQ@mail.gmail.com
Whole thread Raw
Responses Re: Hide exposed impl detail of wchar.c
Re: Hide exposed impl detail of wchar.c
List pgsql-hackers
Hello,

I work on pgrx, a Rust crate (really, a set of them) that allows
people to use Rust to write extensions against Postgres, exporting
what Postgres sees as ordinary "C" dynamic libraries. Unfortunately,
the build system for this is a touch complicated, as it cannot simply
run pgxs.mk, and as-of Postgres 16 it has been periodically failing on
platforms it used to do fine on, due to troubles involved with the
SIMD extension headers.

I have root-caused the exact problem, but the bug is... social, rather
than technical in nature: people with inadequate options at their
disposal have implemented increasingly clever educated guesses that
are increasingly prone to going wrong, rather than just asking anyone
to help them increase their options. Rather than continuing this
trend, I figured I would simply start doing things to hopefully draw
the line here. I will be looking to follow up with the bindgen tools
that fail to handle this correctly, but it would be nice if this
stopped shipping in Postgres 16."${PG_NEXT_MINOR}", as pgrx does need
the definitions in pg_wchar.h to have enough data to correctly
determine database encoding and preserve certain Rust library
invariants ("all Rust strings are correctly-formed UTF-8, anything
else is just a sequence of bytes") without also obliterating
performance.

On the off-chance that everyone agrees with me without reserve, the
attached patch moves the relevant code around (and includes the gory
details). This seems to be unlikely to be the only mildly-exotic build
system failure caused by such an overexposed implementation detail, so
while I'm not married to this particular code motion, it seems best to
improve this some way.

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: On non-Windows, hard depend on uselocale(3)
Next
From: Robert Haas
Date:
Subject: Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM