Re: [HACKERS] RustgreSQL

On 1/8/17 10:28 AM, Joel Jacobson wrote:
>> You'd have a lot more chance writing extensions in Rust though. If you can make it play OK with the exception
handlingin postgres and our memory management, at least. If you really wanted to push this forward... start there. Show
howgreat it is.
 
> Funny you mention, that's actually exactly how these thoughts started
> in my head. I realized I would need to write a C function to do some
> computations that needed to be fast, but since C is dangerous I don't
> know the language well enough I thought "I wish there was a safe and
> fast system language you could
> write database functions in!", and that's how I first found Rust and
> then later this project:
> https://github.com/thehydroimpulse/postgres-extension.rs
> Which allows doing exactly that, writing extensions in Rust.

Somewhat related to that... it would be useful if Postgres had "fenced" 
functions; functions that ran in a separate process and only talked to a 
backend via a well defined API (such as libpq). There's two major 
advantages that would give us:

- Untrusted languages could be made trusted. Currently there's no way to 
limit what a user could do with a function like plpythonu or pl/r, and 
there's no good way to make either of those languages trusted. But if 
the function code was running in a separate process, that process could 
be owned by a user and group (ie: nobody:nogroup) that has no 
permissions to do anything at the OS level. This would make it possible 
for hosting platforms like RDS to offer these languages without undue 
risk. I believe Joe Conway has done some investigation in this area.

- If you had a buggy C function that crashed it wouldn't force us to 
panic the entire database. The fenced process would die, we'd detect 
that and just through a normal error. Currently, C functions can access 
*everything* in backend memory, including shared memory. That's why if 
one crashes we have to panic. Even worse, a bug that corrupts data but 
doesn't always crash could do enormous amounts of damage. The worst a 
bug in a fenced function could do is screw up whatever it's returning to 
the backend.

As for Postgres in general, I think it would be nice if it was easier to 
do some things in a language other than C, for code simplicity reasons. 
The issue with that though is not significantly expanding what's 
necessary to build Postgres. I doubt that rust would meet that criteria.

That said, the community will at least consider things that offer 
*significant* advantages. For example, there's been some discussion 
about making use of LLVM for the executor. Since LLVM is meant to make 
it easier to build new languages, it's possible that it could be used to 
simplify other pieces of code as well.

BTW, I just came across http://safecode.cs.illinois.edu; that might get 
you a lot of the benefits you're looking for in Rust. The description on 
http://llvm.org claims it can be used like Valgrind, which the project 
currently supports.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)