Re: [HACKERS] RustgreSQL

Incredibly unrealistic.

PostgreSQL makes heavy use of variable length arrays. longjmp() is critical to its error handling. Lots of other "unsafe" things.

More to the point though, we struggle to get any acceptance of the most trivial added dependences. Even optionally. We still support a more-than-10-year-old Perl. We still use C89. The project is VERY conservative and expects new releases to run on ancient UNIXes long forgotten by the rest of the world.

This has some advantages. Those weird compilers and platforms help catch bugs. Most of the time they cost us little but minor inconvenience and they're part of why some contributors stay around. 

But it also makes it way harder to make significant change.

IMO the chances of the project switching to Rust are about as high as Oracle Database going open source, or MongoDB declaring that it's changing to SQL as the primary and preferred query language.

The ONLY way I could imagine it happening would be if you could show that it could be done incrementally, in a way that retained support for 10+ year old platforms, with a significant increase in performance and decrease in code size/complexity for converted modules. With minimal or no "rust droppings" (macros everywhere etc) to help such an incremental adaptation along. Even then you'd have to convince a lot of people who know C well (or well enough, or think they do) that it was worth such massive change. If a low pain seamless conversation/adaptation like that were possible I'd have to wonder what Rust could actually offer us over C since it clearly has the same scope for issues if such an intermixture is possible. Kind of a catch-22.

A restricted subset of C++ is a lot more likely. Even then longjmp will cause us pain... I suspect we'd land up having to move to C++ exceptions.

Take a look at elog.c, the memory contexts code, etc. If you think Rust can play well with that, cool. I can't imagine how though.

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.

Then come up with a plan for how you'd handle existing extensions (PostGIS?), external PLs, ecpg, pgxs, etc. Make sure libpq stays totally compatible. All that fun.

I just don't see it happening. Not do I see you suggesting any possible reason why we'd care or want to. You don't want to to learn C so dozens/hundreds of people need to learn Rust. What the?