31–40 of 57 posts
Earlier quoted context omitted.
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".
Earlier quoted context omitted.
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.
Earlier 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
The network round trip to the database can also be a pretty significant performant penalty, especially when iterating over large sets.
Earlier quoted context omitted.
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.
https://www.postgresql.org/docs/current/sql-createtrigger.ht...
> The REFERENCING option enables collection of transition relations
I don't see any examples of statement triggers...
Earlier quoted context omitted.
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".
I concur. Pl/pgsql isn't exactly elegant to be sure, but if you're already in a set-oriented mindset but need to add a sprinkling of imperative logic, it's well suited to the job.
PL/PGSQL is fine for "a bit more than a SELECT statement" and for very simple algorithms of <50 LOC. Anything more and please use a first class language like plrust, plv8, etc.
this 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…
Earlier quoted context omitted.
only when using `unsafe` which this forbids
I don't know much about rust, so it seemed odd to me that just forbidding unsafe would make for a reasonable sandbox. At least for the postgres concept of "trusted language", that's supposed to mean things like closing off access to the filesystem. Not just typical file io calls either, but more obscure stuff like sendfile(). I do see that rust access to sendfile() would be via a syscall, which is in the unsafe categ…
As I read it, it seemed that the unsafe prohibition was more about the safety of the code and not the security of the system.
why would anyone want to use PL/Rust over PL/PQSL? what is the use case?
Earlier quoted context omitted.
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".
The things I notice when working in PLPSQL:
* Ample boilerplate that needs to be correct when it could be inferred.
* Lack of a language server (doesn't help that PLPSQL is often embedded in strings in other files)
* Papercuts like procedures vs functions having different call syntaxes
* No/limited support for encapsulation
* No/limited package management
* Most new languages have syntactic sugar, like implicit returns / everything is an expression