Why you should, actually, rewrite some of it in Rust

Re:Why you should, actually, rewrite some of it in Rust by jeffdavis on Wednesday July 12, 2017 @04:43PM (#14756492)

I am a fan of rust, but this article overstates the simplicity of C/rust integration.

A few examples:

* You may need to use PhantomData in your struct definitions to properly track lifetimes. Not sure I fully understand.

* C functions don't always return. Sometimes they longjmp (c.f. PostgreSQL). Calls into C code need to prepare for this and it's not trivial nor does it generalize to all projects.

* Integrating with the memory management scheme is probably possible but not trivial. For instance, Postgres memory contexts (regions/arenas) can hold any kind of object, and code can switch between them and create/destroy them at will. You could rely on rust to manage it's own memory, with circular references an Rc that might leak.

* Postgres has its own calling convention for SQL-callable functions and conventions for loadable modules. Integrating with this is a pain because macros are hygenic and can't make up new symbols. Maybe procedural macros will help when they arrive.

* Rich APIs that rust supports don't always translate well to C. When integrating with a large application that pushes you toward the lowest-common-denominator APIs.

* A lot of C macros don't translate well to rust and just including a C header in rust is a lot of work. Hoping procedural macros will help here too.

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by anarazel on Wednesday July 12, 2017 @05:07PM (#14756692)

Btw, are you planning to work on a thin integration layer between rust and postgresql? Sufficient to be able to write UDFs in rust? That's imo the most realistic start to get some experience w/ rust in the postgres community, and it provides value on its own.

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by jeffdavis on Wednesday July 12, 2017 @05:19PM (#14756793)

I've made some progress. Not quite as thin as I had hoped ;-)

I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author.

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by anarazel on Wednesday July 12, 2017 @06:24PM (#14757204)

> I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author.

Why exactly is that? I'd have expected a C wrapper to take care of most of that? Are you concerned about the Datum<->native type C macros?

Are you planning/hoping for this to be all safe, or is there going to be unsafety in the wrapper?

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by jeffdavis on Wednesday July 12, 2017 @08:06PM (#14757740)

Creating a new module or UDF requires exporting new special symbols for V1 calling convention.

Rust's hygenic macros don't let you do that. So defining a UDF has a bunch of boilerplate, unless I am missing something.

Procedural macros should alleviate this, but it will be a while. I might just release and document the boilerplate needed.

EDIT: Yes, I am trying to be mostly safe. I will see how close I can get for at least the basic stuff.

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by anarazel on Wednesday July 12, 2017 @11:08PM (#14758446)

> Creating a new module or UDF requires exporting new special symbols for V1 calling convention.

Right - but I don't think you need to do so. That'd only be required if you'd use language 'C' - why not instead use language 'rust'. That'll force a simple wrapper function which looks up and calls the real function, but that's fairly harmless, no? Might actually be good, because you can do some extra checks and conversions there.

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by jeffdavis on Wednesday July 12, 2017 @11:27PM (#14758496)

There are some extension APIs that demand C. But perhaps I dismissed the idea of plrust too quickly and there is room for both?

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by anarazel on Thursday July 13, 2017 @12:24AM (#14758684)

I'd say it'd be better to let PL handlers decide whether they can be used in those cases. IIRC those cases largely exist because you need to be able to deal with pointers which existing pls weren't able to...

[ Parent | on HN ]