Hide exposed impl detail of wchar.c
От | Jubilee Young |
---|---|
Тема | Hide exposed impl detail of wchar.c |
Дата | |
Msg-id | CAPNHn3oKJJxMsYq+qLYzVJOFrUcOr4OF1EC-KtFT-qh8nOOOtQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Hide exposed impl detail of wchar.c
Re: Hide exposed impl detail of wchar.c |
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: