Jubilee

Alright, there were several delays due to... various points of confusion, some of them entertaining, most of them not, but I have now managed to get a global allocator override...

As far as pulling in `std` in spite of the crate being `#![no_std]`: I am not entirely sure how `#![no_std]` is circumvented here if you directly annotate the crate, but...

Oh yeah, `extern crate std`. Yeah, I am pretty sure that's resoluble by just specifying `std` again, using `rustc --extern` to control the mapping, since PL/Rust implies some kind of...

Correct. I confirmed last night that we have to build a "full-fledged" new std instead of a "mere" override, as a `--extern` itself doesn't do enough. So `-Zbuild-std` it is.

Currently blocked on https://github.com/tcdi/plrust/pull/49 which requires a PR to PGX which I had been drafting. Likely need to toggle a feature based on inclusion of the Postgres allocator or not.

That was unblocked (mostly) and also I got everything building for postgrestd and just need to document and push everything up properly now. This will depend on several forked crates...

As of https://github.com/tcdi/plrust/pull/56 a preliminary `x86_64-postgres-linux-gnu` tuple works on GNU/Linux with Postgres 14, and it passes build/test cycles on that (though I... somehow managed to break macOS in CI, even...

Yesterday I realized and implemented everything that had to happen to effectuate a new version of the Rust target-specific `std::sys` implementation that has most of the security properties we're looking...

Main insight from spending a bit of time investigating it today: Aside from blocking off `std::fs` from doing anything of interest, the new variant + the changes in `pgx` in...

Even libc also no longer requires forking with the revised approach! As panic handling currently more or less Just Works (well, after I fixed a few cases which surfaced inadequacies...