> 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?

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.

> 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.

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

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...