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 handling in postgres and our memory management,
at least. If you really wanted to push this forward... start there. Show how
great 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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
