On Mon, Sep 12, 2022 at 11:29:12AM -0400, Tom Lane wrote:
> Lev Kokotov <lev@hyperparam.ai> writes:
> >> 3. Do we gain anything besides compiler hints? Postgres development is
> >> hard due to interference of complex subsystems. It will be even harder if
> >> those systems will be implemented in different languages.
>
> > Rust gives many things we wanted for decades:
>
> > 1. No undefined behavior
> > 2. No memory leaks, guaranteed at compile time
>
> Really? It seems impossible to me that a language that even thinks
> it can guarantee that could interoperate with the backend's memory
> management. And that's not something we are interested in replacing.
Indeed, it can only guarantee that if you rely on regular safe rust where
lifetimes can be checked. To use the memory context infrastructure you would
need to use unsafe rust, and when you do that you're back with the same
problems.
> > I took a small part of Postgres to get started, so just as a PoC; it
> > compiles and runs though. Larger parts will take more work (deleting code,
> > not just swapping object files), and more fancy things like PG_TRY() and
> > friends will have to be rewritten, so not a short and easy migration.
>
> Yeah, that's what I thought. "Allow some parts to be written in
> language X" soon turns into "Rewrite the entire system in language X,
> including fundamental rethinking of memory management, error handling,
> and some other things". That's pretty much a non-starter.
Also, unless I'm missing something the modified code will only work for
frontend programs, where palloc / pfree are really malloc / free calls.
The rewritten BuildRestoreCommand won't return a palloc'd string on the
backend, so the recovery TAP tests should crash when using it.
