A Rust procedural language handler for PostgreSQL
github.com
github.com
Anyway, kudos for making it available.
Engineering is tradeoffs, the limiting factor in most databases is I/O; if you can shift your I/O around to do less of it with a stored procedure then you should probably do it, and having a breakout from SQL on the database itself can achieve that.
The reason it scares DBAs is because while I/O is the primary constraint on a DB, everything else is also in finite supply, and people tend to forget how centralised and repeated a stored procedure can become. Especially if its on the hotpath. Developers have a habit of using stored procedures to make their application code easier to reason about rather than trying to minimise disk access.
YMMV as with everything, but its a really nice capability to use rust for this, for the execution performance, quick start time and type safety.
Thanks for the upvoting.
Really complex things could be delivered, main issue was always tradeoffs of Oracle itself (portability of Oracle vs Performance loss compared to more native systems) and licensing.
Postgresql extensions are great in that you can compile them and link them into a running database.
Cannot tell, I am more of an Oracle and SQL Server kid of person when it comes to deep RDMS knowledge.
It is now available on RDS, too.
PG17 support was promised last July but has yet to materialize.
I know OSS authors owe us nothing and it’s their choice to do what they will, but it does make it hard for others to want to embrace these projects when they stagnate.
“pgrx has been going through some major work to help improve its overall soundness as it relates to managing Postgres-allocated memory. Once that work is complete, pl/rust will get a refresh.”
If not, how can it be "trusted" if Rust has unsafe escapes that can read and write arbitrary memory? (And also, the Rust compiler has known soundness issues that makes it possible to run unsafe code in safe Rust,
>> The intent is that plrust-trusted-pgrx can evolve independently of both pgrx and plrust. There are a few "unsafe" parts of pgrx exposed through plrust-trusted-pgrx, but PL/Rust's ability to block unsafe renders them useless by PL/Rust user functions.
>> What about Rust compiler bugs? PL/Rust uses its own rustc driver which enables it to apply custom lints to the user's LANGUAGE plrust function. In general, these lints will fail compilation if the user's code uses certain code idioms or patterns which we know to have "I-Unsound" issues.
>> The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. postgrestd is a specialized Rust compilation target which disallows access to the filesystem and the host operating system.
etc.
Relying on the compiler to do sandboxing is theoretically possible, as done by the Singularity and Midori operating systems from Microsoft (they ran all user programs in kernel mode, without paging, relying only on the compiler to prevent an user from reading memory from another user). But in practice this can't be done with a compiler full of holes like rustc, you would need a compiler that was designed for this from the ground up.