On 11/15/19 8:59 AM, Andrew Dunstan wrote: > On 11/14/19 3:21 PM, Alvaro Herrera wrote: >> On 2019-Nov-14, Andrew Dunstan wrote: >> >>> I guess this would work. There would have to be a deal of code to load >>> the library and lookup the symbol. Do we really think it's worth it? >>> Leveraging shared_preload_libraries makes this comparatively simple. >> Using the generic interface has the drawback that the user can make more >> mistakes. I think that's part of Bruce's issue with it (although I may >> misinterpret.) >> >> I think if you add most of it as a new entry point in dfmgr.c (where you >> can leverage internal_library_load) and returns a function pointer to >> the user specified function, it's all that much additional code. >> >> (I don't think you can use load_external_function as is, because it >> assumes fmgr V1 calling convention, which I'm not sure serves your case. >> But then maybe it does. And if not, then those 10 lines should be very >> similar to the code you'd need to add.)
I've just been looking at that. load_external_function() doesn't actually do anything V1-ish with the value, it just looks up the symbol using dlsym and returns it cast to a PGFunction. Is there any reason I can't just use that and cast it again to the callback function type? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services