On 8 Jan. 2017 17:10, "Joel Jacobson" <j...@trustly.com> wrote:

Is this completely unrealistic or is it carved in stone PostgreSQL will
always be a C project forever and ever?

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

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?

Reply via email to