why would anyone want to use PL/Rust over PL/PQSL? what is the use case?
PLPSQL is an awful language for anything less than the highest level glue code
PL/Rust 1.0: now a trusted language for Postgres
21–30 of 57 posts
Re: PL/Rust 1.0: now a trusted language for Postgres
#22why would anyone want to use PL/Rust over PL/PQSL? what is the use case?
> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language Use to write PostgreSQL functions in Rust. Also > The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.
A crucial facet of optimization for computational triggers in PostgreSQL pertains to the implementation of event triggers, which enable operations to be executed in bulk (per DML statement) rather than on a per-row basis. It appears that, at present, PL/Rust has not incorporated support for event triggers. According to the documentation:
> Event Triggers and DO blocks are not (yet) supported by PL/Rust.
Re: PL/Rust 1.0: now a trusted language for Postgres
#23why would anyone want to use PL/Rust over PL/PQSL? what is the use case?
PLPSQL is an awful language for anything less than the highest level glue code
Can you give some examples of why you think this? I'm sincerely curious as someone who uses PLPSQL nearly every day and knows it is not perfect, but surprised to hear it is "awful".
Re: PL/Rust 1.0: now a trusted language for Postgres
#24this is an exciting development for Postgres. Since PL/Rust is now a trusted language, it means that cloud providers like RDS and Supabase will be able to provide it. This means that you can write your database functions in rust, as an alternative to pgplsql / plv8. (disclosure: i work at supabase)
Thank you for saying "disclosure" instead of "disclaimer".
Re: PL/Rust 1.0: now a trusted language for Postgres
#25this is an exciting development for Postgres. Since PL/Rust is now a trusted language, it means that cloud providers like RDS and Supabase will be able to provide it. This means that you can write your database functions in rust, as an alternative to pgplsql / plv8. (disclosure: i work at supabase)
Can… but how long until they actually do provide it? I’m a big fan of PostgreSQL and it’s constantly an annoyance to find cool new capabilities provided by extensions I can never use since I’m not going to manage my own database in a critical environment for a lot of reasons… I’ve done it before, I know how hard it is to do well, and I don’t want this to be my job anymore… so when I find cool stuff like vector search…
We are launching something with the RDS team this week that will make it very easy to install your own extensions that are written in Trusted Languages. We will share more on Friday.
In terms of pl/rust becoming available on RDS and supabase: months. It’s going through security audits now
Re: PL/Rust 1.0: now a trusted language for Postgres
#26this is an exciting development for Postgres. Since PL/Rust is now a trusted language, it means that cloud providers like RDS and Supabase will be able to provide it. This means that you can write your database functions in rust, as an alternative to pgplsql / plv8. (disclosure: i work at supabase)
Thank you for saying "disclosure" instead of "disclaimer".
Disclaimer: I know what I'm talking about.
Re: PL/Rust 1.0: now a trusted language for Postgres
#27Earlier quoted context omitted.
Normally yes, but it looks like the trusted PL/Rust being discussed here is limited to some subset of Rust. They specifically note that `unsafe` code is not allowed, which means you can't (for example) implement your own syscalls or construct a pointer into postgres internals memory. However, they make it clear that this is not intended to be your only defence against an attacker: > Note that this is done on a best-e…
I don't think it's really any defence at all against an attacker. I don't think Rust's `unsafe` was ever intended to be a security boundary. Surely all a "sufficiently motivated" attacker would need to do is peruse the unsound bugs on GitHub? https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... Those aren't considered to be security issues. Makes me wonder what the point of banning `unsafe` is at all. You'…
The trust is not just banning unsafe, it is using a limited std:
> The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions.
Re: PL/Rust 1.0: now a trusted language for Postgres
#28Earlier quoted context omitted.
Can… but how long until they actually do provide it? I’m a big fan of PostgreSQL and it’s constantly an annoyance to find cool new capabilities provided by extensions I can never use since I’m not going to manage my own database in a critical environment for a lot of reasons… I’ve done it before, I know how hard it is to do well, and I don’t want this to be my job anymore… so when I find cool stuff like vector search…
We are launching something with the RDS team this week that will make it very easy to install your own extensions that are written in Trusted Languages. We will share more on Friday. In terms of pl/rust becoming available on RDS and supabase: months. It’s going through security audits now
It will be very hard for other database engines to keep up if this gets implemented by cloud vendors. MySQL would get marginalized further and further not just in the relative lack of SQL features, but all the easily available add-ons the community will inevitably write for Postgres with no viable answer from its competition.
Re: PL/Rust 1.0: now a trusted language for Postgres
#29Earlier quoted context omitted.
> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language Use to write PostgreSQL functions in Rust. Also > The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.
A crucial facet of optimization for computational triggers in PostgreSQL pertains to the implementation of event triggers, which enable operations to be executed in bulk (per DML statement) rather than on a per-row basis. It appears that, at present, PL/Rust has not incorporated support for event triggers. According to the documentation: > Event Triggers and DO blocks are not (yet) supported by PL/Rust.
Event triggers fire on DDL changes, not DML. You're thinking of statement-level triggers.
As far as event triggers and DO-blocks, that omission seems fine to me. Especially DO-blocks, which are essentially an inline code, one-off escape hatch in the middle of other SQL. Rust would not be helping any performance-sensitive critical paths in those cases.
Re: PL/Rust 1.0: now a trusted language for Postgres
#30Earlier quoted context omitted.
> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language Use to write PostgreSQL functions in Rust. Also > The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.
As someone who have done a lot of database development, none of these sound advantageous Using a text oriented language like Perl with a good regexp engine might DB performance, comes from indexes , table partitioning and in-memory tables and to compile query execution plans, so you save some time the very first you run a procedure
DB performance also comes from size efficiency of user-defined data types, user-defined operator functions (typically for use with those user-defined data types), etc.
Smaller, more efficient types directly translate to less disk usage and smaller indexes, both of which measurably improve database performance.