Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PL/Rust 1.0: now a trusted language for Postgres

tcdi.github.io

Post reply on HN
Print view View original

41–50 of 57 posts

Re: PL/Rust 1.0: now a trusted language for Postgres

#41

Post by ttfkam »

asah wrote: post #36
ttfkam wrote: post #31

Earlier quoted context omitted.

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.

no seriously, PL/pgsql is pretty horrible and obscure. But aside from subjective comments, there's very few algorithms available for it, approximately 0% of engineers know it and it's not taught in school, has little tooling compared with a first class programming language, you can't run pl/pgsql code outside of PostgreSQL, and (tell me when to stop) PL/PGSQL is fine for "a bit more than a SELECT statement" and for v…

The decision between pl/pgsql and something like plv8 isn't LOC. It's whether the solution best fits a set-oriented model or a procedural model. Both are valid, just different use cases.

There are a lot of cases where plv8 will thrash back and forth between the internals of Postgres and C and its v8 engine. These are usually the cases where set theory dominates the solution space.

On the flip side, if you're doing a lot of filter/map/reduce on large JSON payloads, plv8 is demonstrably better than pl/pgsql.

Right tool. Right job.

Re: PL/Rust 1.0: now a trusted language for Postgres

#42

Post by ttfkam »

samanator wrote: post #35
ttfkam wrote: post #29

Earlier quoted context omitted.

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.

You're right! My mistake. I was thinking of statement triggers. 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...

https://stackoverflow.com/a/72397774

Note the use of new_table and old_table as aliases. Instead of single records in NEW and OLD, you can select against new and old sets of records.

Re: PL/Rust 1.0: now a trusted language for Postgres

#43

Post by techdragon »

kiwicopple wrote: post #25
techdragon wrote: post #12

Earlier 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

Wonderful! I’ll be checking for news on Friday. Thanks for replying, otherwise I’d probably not have noticed till a couple months from now when I next check the AWS service feature release news.

Re: PL/Rust 1.0: now a trusted language for Postgres

#44

Post by vlovich123 »

ekimekim wrote: post #6
zabzonk wrote: post #4

Earlier quoted context omitted.

cannot rust functions do anything a c function can?

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…

So you have to give them your rust code to compile on your behalf then?

Re: PL/Rust 1.0: now a trusted language for Postgres

#45

Post by pjmlp »

mkl95 wrote: post #18
systems wrote: post #17

why 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.

Stored procedures are compiled to native code in any respectfull RDMS (Oracle, SQL Server, DB2,...), and I assume same applies to PostgreSQL.

Re: PL/Rust 1.0: now a trusted language for Postgres

#46

Post by pjmlp »

ttfkam wrote: post #30
systems wrote: post #19

Earlier quoted context omitted.

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.

I assume PL/pg is not behind the curve in relation to PL/SQL and T-SQL for UDTs.

Re: PL/Rust 1.0: now a trusted language for Postgres

#48

Post by pjmlp »

asah wrote: post #36
ttfkam wrote: post #31

Earlier quoted context omitted.

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.

no seriously, PL/pgsql is pretty horrible and obscure. But aside from subjective comments, there's very few algorithms available for it, approximately 0% of engineers know it and it's not taught in school, has little tooling compared with a first class programming language, you can't run pl/pgsql code outside of PostgreSQL, and (tell me when to stop) PL/PGSQL is fine for "a bit more than a SELECT statement" and for v…

The same engineers that use to rave about NoSQL a couple of years ago?

Re: PL/Rust 1.0: now a trusted language for Postgres

#50

Post by IshKebab »

feike wrote: post #27
IshKebab wrote: post #16

Earlier quoted context omitted.

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. https://github.com/tcdi/postgrestd

That doesn't matter. If you can use `unsafe` you can make syscalls directly.
Post reply on HN