A Rust procedural language handler for PostgreSQL(github.com)
github.com
A Rust procedural language handler for PostgreSQL
https://github.com/tcdi/plrust
21 comments
Upvoting because its actually good advice (and someone has flagged it for some reason).
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.
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.
Which is why, when we're talking about heavy weights in the RDMS space, all provide tooling for debugging and optimising stored procedures.
Thanks for the upvoting.
Thanks for the upvoting.
as much as I dislike (understatement) Oracle my few encounters with it not only showed ability to provide an "API" through SQL to client apps, there was also apparently quite capable JVM inside.
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.
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.
I administer a few Postgresql databases and some extensions are really important for us. Foreign Data Tables, for instance, are great for interconnecting with other databases. I've also heavily used Java stored procs before.
Postgresql extensions are great in that you can compile them and link them into a running database.
Postgresql extensions are great in that you can compile them and link them into a running database.
Usually compiling and linking extensions is a basic feature from enterprise level RDMS, PosgreSQL is only doing what is already expected.
Previously: PL/Rust 1.0: now a trusted language for Postgres (https://news.ycombinator.com/item?id=35501065)
It is now available on RDS, too.
It is now available on RDS, too.
It’s hard to feel enthused by this when there’s been no traction for nearly a year now on the project.
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.
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.
According to https://github.com/tcdi/plrust/issues/412
“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.”
“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.”
Does it compile to wasm or otherwise sandbox the Rust binary?
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,
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,
>> PL/Rust uses the Rust compiler itself to wholesale disallow the use of unsafe in user functions. If a LANGUAGE plrust function uses unsafe it won't compile.
From https://plrust.io/plrust.html
From https://plrust.io/plrust.html
Note that third party crates are still allowed to use `unsafe`. Moreover the rust compiler is not infallible and there are some soundness issues that have yet to be fixed.
Yes; they claim to also address this. I'm not an expert and so can't pass judgement on their claims, but here's what they write (which you would see if you clicked the link and scrolled a bit):
>> 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.
>> 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.
The approach of patching soundness issues seems pretty dangerous to me, since nothing guarantees there won't be more, or that they even perfectly cover the current ones.
The other procedural languages are also not mystically secure from soundness problems, people just fuzz them less.
That's why they should all be sandboxed. Just compile them to wasm and this greatly reduces the surface area of exploits in practice; or, run them in a separate process and sandbox with seccomp (and talk to them with IPC). The former approach actually has less overhead for small components, or at least that's what Firefox devs found out https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
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.
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.
Works well in RDS… but it’s an absolute nightmare to dockerize and set up locally. I really wish the team would have a much cleaner guide for how to do this.
Anyway, kudos for making it available.