3 ms·
> 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 t
by anarazel 9y ago
> 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?
- jeffdavis 9y agoCreating 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.
- anarazel 9y ago> 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.
- jeffdavis 9y agoThere are some extension APIs that demand C. But perhaps I dismissed the idea of plrust too quickly and there is room for both?
- anarazel 9y agoI'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...